linux-kernel - Re: select validation (was: Re: [2.6 patch] HID: fix default building of all quirky devices)

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:	Thu, 16 Oct 2008 11:47:55 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
cc:	Jiri Kosina <jkosina@...e.cz>, Adrian Bunk <bunk@...nel.org>,
	zippel@...ux-m68k.org, sam@...nborg.org,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	Jiri Slaby <jirislaby@...il.com>,
	Mauro Carvalho Chehab <mchehab@...hat.com>
Subject: Re: select validation (was: Re: [2.6 patch] HID: fix default building
 of all quirky devices)

On Thu, 16 Oct 2008, Geert Uytterhoeven wrote:
> 
> Would it be possible for kconfig to check for invalid usage of select?
> 
> Like you should not use select to enable something that has
> dependencies. However, that would fail in case both the selector option
> and the selected option depend on the same.

Well, at least in theory you may actually want to select something that 
has dependencies, even if you don't want to select the dependencies.

For example, some feature may be enabled by default on some architecture 
or with some config. Example:

	bool SUPPORT_FEATURE
		default y
		depends on EXPERIMENTAL
		depends on !EMBEDDED
		depends on X86

which is just another way of saying

	bool SUPPORT_FEATURE
		default X86 && !EMBEDDED && EXPERIMENTAL

and it's still possible that some code wants to do a

	select SUPPORT_FEATURE

because the dependency isn't a _code_ dependency, it's a default-value 
dependency.

Now, you could say that then you should use that second version (ie the 
"default X86 && !EMBEDDED && EXPERIMENTAL" version), but the thing is, 
"depends on" is actually a more powerful and can result in more readable 
setup (because you can have multiple "depends on" lines and they are all 
logically anded together.

Do we do that? I dunno. But I wouldn't be surprised if we do.

		Linus
--
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/