linux-kernel - Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 4 Mar 2024 10:24:25 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Guenter Roeck <groeck@...gle.com>
Cc: Linus Torvalds <torvalds@...uxfoundation.org>, 
	Nikolai Kondrashov <spbnick@...il.com>, Helen Koike <helen.koike@...labora.com>, linuxtv-ci@...uxtv.org, 
	dave.pigott@...labora.com, linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org, 
	linux-kselftest@...r.kernel.org, gustavo.padovan@...labora.com, pawiecz@...labora.com, 
	tales.aparecida@...il.com, workflows@...r.kernel.org, kernelci@...ts.linux.dev, 
	skhan@...uxfoundation.org, kunit-dev@...glegroups.com, nfraprado@...labora.com, 
	davidgow@...gle.com, cocci@...ia.fr, Julia.Lawall@...ia.fr, laura.nao@...labora.com, 
	ricardo.canuelo@...labora.com, kernel@...labora.com, gregkh@...uxfoundation.org
Subject: Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for
 Kernel Testing

On Sat, Mar 02, 2024 at 02:10:51PM -0800, Guenter Roeck wrote:
> On Thu, Feb 29, 2024 at 12:21 PM Linus Torvalds
> <torvalds@...uxfoundation.org> wrote:
> >
> > On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov <spbnick@...il.com> wrote:
> > >
> > > However, I think a better approach would be *not* to add the .gitlab-ci.yaml
> > > file in the root of the source tree, but instead change the very same repo
> > > setting to point to a particular entry YAML, *inside* the repo (somewhere
> > > under "ci" directory) instead.
> >
> > I really don't want some kind of top-level CI for the base kernel project.
> >
> > We already have the situation that the drm people have their own ci
> > model. II'm ok with that, partly because then at least the maintainers
> > of that subsystem can agree on the rules for that one subsystem.
> >
> > I'm not at all interested in having something that people will then
> > either fight about, or - more likely - ignore, at the top level
> > because there isn't some global agreement about what the rules are.
> >
> > For example, even just running checkpatch is often a stylistic thing,
> > and not everybody agrees about all the checkpatch warnings.
> >
> 
> While checkpatch is indeed of arguable value, I think it would help a
> lot not having to bother about the persistent _build_ failures on
> 32-bit systems. You mentioned the fancy drm CI system above, but they
> don't run tests and not even test builds on 32-bit targets, which has
> repeatedly caused (and currently does cause) build failures in drm
> code when trying to build, say, arm:allmodconfig in linux-next. Most
> trivial build failures in linux-next (and, yes, sometimes mainline)
> could be prevented with a simple generic CI.

Ultimately, the question here is about funding. Can we expect DRM CI to
pay for builders out of the X.org foundation pocket to build kernel
configurations that are seeing close to no development (arm), or not
having any driver for (xtensa, m68k)?

And if we would turn the argument around, I don't really expect, say,
the clock framework, to validate that all DRM kunit tests pass for each
commit they merge, even though one of them could totally break some of
the DRM tests.

If anything, it's more of a side-effect to the push for COMPILE_TEST
than anything.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)