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]

Message-ID: <20240304-ludicrous-grinning-goldfish-090aac@houat>
Date: Mon, 4 Mar 2024 17:05:05 +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 Mon, Mar 04, 2024 at 07:46:34AM -0800, Guenter Roeck wrote:
> On Mon, Mar 4, 2024 at 1:24 AM Maxime Ripard <mripard@...nel.org> wrote:
> [ ... ]
> >
> > If anything, it's more of a side-effect to the push for COMPILE_TEST
> > than anything.
> >
> 
> If the drm subsystem maintainers don't want people to build it with
> COMPILE_TEST while at the same time not limiting it to platforms where
> it doesn't even build, I'd suggest making it dependent on
> !COMPILE_TEST.

I don't think we want anything. My point was that you can't have an
option that is meant to explore for bad practices and expose drivers
that don't go through the proper abstraction, and at the same time
complain that things gets broken. It's the whole point of it.

> The same applies to all other subsystems where maintainers don't want
> build tests to run but also don't want to add restrictions such as
> "64-bit only". After all, this was just one example.

We have drivers for some 32 bits platforms.

Maxime

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