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 for Android: free password hash cracker in your pocket

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

Message-ID: <20081016193103.GC22554@cs181140183.pp.htv.fi>
Date:	Thu, 16 Oct 2008 22:31:03 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Jiri Kosina <jkosina@...e.cz>, 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, Oct 16, 2008 at 11:47:55AM -0700, Linus Torvalds wrote:
> 
> 
> 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

Such constructs without a prompt are for a different usecase than what 
you have in mind, there wouldn't be EXPERIMENTAL or EMBEDDED in the 
dependencies, this is used for stuff like

config X86_HT
        bool
        depends on SMP
        depends on (X86_32 && !X86_VOYAGER) || X86_64
        default y

And that's usually not the kind of symbol that should get selected.


In reality your example would be:

config SUPPORT_FEATURE
        bool "support feature" if EMBEDDED
        default y
        depends on X86 && 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.
>...

I'd be more concerned about dependencies that are used to make the 
kconfig UI better.

Dependencies on options like NETDEV_1000 are not code dependencies.

> 		Linus

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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