linux-kernel - Re: [PATCH] build some drivers only when compile-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: <51C01E04.2050908@suse.cz>
Date:	Tue, 18 Jun 2013 10:44:52 +0200
From:	Michal Marek <mmarek@...e.cz>
To:	balbi@...com
Cc:	Jiri Slaby <jslaby@...e.cz>, Jeff Mahoney <jeffm@...e.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	jirislaby@...il.com, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	linux-usb@...r.kernel.org,
	Florian Tobias Schandinat <FlorianSchandinat@....de>,
	linux-geode@...ts.infradead.org, linux-fbdev@...r.kernel.org,
	Richard Cochran <richardcochran@...il.com>,
	netdev@...r.kernel.org, Ben Hutchings <ben@...adent.org.uk>,
	"Keller, Jacob E" <jacob.e.keller@...el.com>, tomi.valkeinen@...com
Subject: Re: [PATCH] build some drivers only when compile-testing

Dne 18.6.2013 10:34, Felipe Balbi napsal(a):
> Hi,
> 
> On Tue, Jun 18, 2013 at 10:24:40AM +0200, Jiri Slaby wrote:
>>>>> Sam Ravnborg (the kconfig ex-maintainer) once wrote that
>>>>> he doesn't want to extend the kconfig language for this
>>>>> purpose (which I support). That a config option is fine and
>>>>> sufficient in this case [1]. Except he called the config
>>>>> option "SHOW_ALL_DRIVERS". Adding the current maintainer to
>>>>> CCs ;).
>>>> 
>>>> I agree with Sam. 'depends on XY || COMPILE_TEST' is quite 
>>>> self-explanatory. And even if it's not, you can look up the
>>>> help text for COMPILE_TEST. With "archdepends on" or
>>>> "available on", you need to know what to look for to override
>>>> the dependency.
>>> 
>>> you will still end up with:
>>> 
>>> depends on (ARCH_OMAP || ARCH_EXYNOS || ARCH_DAVINCI ||
>>> ARCH_PPC || ...)
>>> 
>>> And every now and again that particular line will be updated
>>> to add another arch dependency.
>> 
>> But that is perfectly fine *when* the driver is supported on
>> those archs only.
>> 
>> And come on, how much often will this "every now and again"
>> happen? We don't have that much cases where a driver is augmented
>> to work on another arch or platform. It either works on all of
>> them => doesn't need COMPILE_TEST, or work on one or two arches
>> at most.
> 
> MUSB alone has 8 different arch choices. Before, it used to be that
> core driver was dependendent on all of them, so whenever someone
> wanted to build MUSB for another arch, they had to introdude their
> glue code and modify the dependency of the core driver.

But that you have complex dependencies in some drivers is mostly
orthogonal to the two choices of syntax, isn't it?

depends on ARCH1 || ARCH2 || .... || ARCH8 || COMPILE_TEST

vs.

archdepends on ARCH1 || ARCH2 || .... || ARCH8

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/