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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sun, 20 May 2007 20:30:49 +0200
From:	Adrian Bunk <bunk@...sta.de>
To:	Trent Piepho <xyzzy@...akeasy.org>
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 02:52:14AM -0700, Trent Piepho wrote:
> On Sun, 20 May 2007, Satyam Sharma wrote:
> > On 5/20/07, Adrian Bunk <bunk@...sta.de> wrote:
> > > On Sun, May 20, 2007 at 05:25:24AM +0530, Satyam Sharma wrote:
> > > > On 5/20/07, Adrian Bunk <bunk@...sta.de> wrote:
> > > >> On Sun, May 20, 2007 at 05:06:33AM +0530, Satyam Sharma wrote:
> > > >> > On 5/20/07, Adrian Bunk <bunk@...sta.de> wrote:
> > > >> There are cases where "default .. if .." is the right idiom, but there
> > > >> are also cases where "select" is the right idiom. And for helper code
> > > >> like ATARI_KBD_CORE, "select" is the right idiom.
> > > >
> > > > ATARI_KBD_CORE, unlike MII, is defined only by some archs. And the
> > > > correct (most widely used or standard, in any case) idiom for that is
> > > > "default .. if ..". Or perhaps you can convert those helper code options in
> > > > arch/.../config's over to select too, as an exercise? :-)
> > >
> > > Perhaps not as an exercise, but actually for real.
> > >
> > > We had "fixed" such warnings in the past similar to your patch, but that
> > > was actually a mistake.
> > >
> > > And "correct" can easily be the opposite of "most widely used or standard"
> > > if you discover that you did it wrong in the past.
> >
> > In that case the correct approach here too would be to _shift_
> > ATARI_KBD_CORE from arch/m68k/Kconfig to drivers/input/Kconfig
> > and *then* use "select" from the config options that require it in
> > drivers/input/keyboard/Kconfig and drivers/input/mouse/Kconfig
> >
> > (and repeat for other such cases in arch/...)
> 
> You don't need a huge '||' chain, you can always have more than one default
> line:
> 
> config ATARI_KBD_CORE
> 	bool
> 	default y if KEYBOARD_ATARI
> 	default y if MOUSE_ATARI
> 
> Basically a line "config A \n select B" is transformed into "config B \n
> default y if A".  It's the same number of lines, they're just in a new place.

Only if the select'ed option is a bool.
With tristates they are doubled.

And for user visible options like MII you need an additional helper 
option.

And the "just in a new place" makes a big difference in readability.
Compare the version of arch/mips/Kconfig in kernel 2.6.0 with the 
version in current kernels.
E.g. tell me whether there's any system that doesn't select any 
SYS_SUPPORTS_*_ENDIAN. There are possible errors that can be spotted 
much easier when using "select" at the right places.

> Another alternative would be to shift the arch specific drivers to a file
> that's arch specific.  e.g. move MOUSE_ATARI from drivers/input/mouse/Kconfig
> to arch/m68k/Kconfig.

Where is for a Kconfig user (person compiling her own kernel) the 
logical place to search for the Atari mouse driver option?

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/