linux-kernel - Re: RFC: kconfig select warnings bogus?

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] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 20 May 2007 20:23:07 +0200
From:	Adrian Bunk <bunk@...sta.de>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	Satyam Sharma <satyam.sharma@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Sam Ravnborg <sam@...nborg.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Roman Zippel <zippel@...ux-m68k.org>,
	Kumar Gala <galak@...nel.crashing.org>,
	Simon Horman <horms@...ge.net.au>
Subject: Re: RFC: kconfig select warnings bogus?

On Sun, May 20, 2007 at 03:09:10PM +0200, Stefan Richter wrote:
>...
> Since you mention "select":  My opinion about the "select" dialect of
> "depends on" is that the UIs should be improved and "select" should be
> removed from the Kconfig language.  What do we "select"?  Typically we
> "select" an option on which /n/ other options depend on but which itself
> does depend on none or few options higher up.  The UIs could be able to
> figure this out for themselves, or if necessary by a hint tacked onto
> library-type options.  That is, instead of
> 
> 	config A
> 		tristate "driver A"
> 		select L
> 
> 	config B
> 		tristate "driver B"
> 		select L
> 
> 	config L
> 		tristate "library L"
> 
> write
> 
> 	config A
> 		tristate "driver A"
> 		depends on L
> 
> 	config B
> 		tristate "driver B"
> 		depends on L
> 
> 	config L
> 		tristate "library L"
> 		hint THIS_IS_A_LIBRARY
> 
> Now let UIs "make oldconfig", "make menuconfig", "make randconfig" deal
> with the hint or ignore the hint --- according to the purpose and
> usability requirements of the respective UI.  The "hint
> THIS_IS_SOMETHING" isn't even necessary in many cases to detect roles of
> options, because their position in the dependency graph is already
> saying something about it.
>...

Example where your proposal wouldn't work well:

config MIPS_ATLAS
        bool "MIPS Atlas board"
        select SYS_SUPPORTS_LITTLE_ENDIAN
        select SYS_SUPPORTS_BIG_ENDIAN

config SYS_SUPPORTS_BIG_ENDIAN
        bool

config CPU_BIG_ENDIAN
        bool "Big endian"
        depends on SYS_SUPPORTS_BIG_ENDIAN


Where's the value of allowing an UI to ignore hints? If an UI would 
ignore all hints on SYS_SUPPORTS_BIG_ENDIAN you would no longer be able 
to configure a kernel on this architecture.

And there's no way for an UI to figure out the direction of the options - 
with "select" the only reasonable direction is fixed for all UIs.

"select" might have room for improvements especially in the area of 
dependencies of select'ed options, but replacing it with overloading
"depends on" plus hints wouldn't be a good solution.

> Stefan Richter

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/