linux-kernel - Re: non-choice related config entries within choice

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:	Wed, 16 Jan 2008 14:50:50 +0100
From:	Sam Ravnborg <sam@...nborg.org>
To:	Jan Beulich <jbeulich@...ell.com>
Cc:	Roman Zippel <zippel@...ux-m68k.org>,
	Randy Dunlap <randy.dunlap@...cle.com>, david-b@...bell.net,
	linux-kernel@...r.kernel.org
Subject: Re: non-choice related config entries within choice

On Wed, Jan 16, 2008 at 01:46:57PM +0000, Jan Beulich wrote:
> >But one feature I really would like to see is named chocies so we can do stuff like:
> >
> >choice X86_PROCESSOR
> >
> >config GENERIC_PROCESSOR
> >	bool "A generic X86 processor"
> >endchoice
> >
> >
> >...
> >
> >choice PPC_PROCESSOR
> >
> >config GENERIC_PROCESSOR
> >	bool "A generic PowerPC processor
> >
> >endchoice
> >
> >The issue here is that we do not today allow the same config option
> >to appear if more than one choice.
> 
> I want named choices, too, but for a different purpose (and not
> unconditionally): Currently, a choice really can just be a selection
> between individual boolean settings or (as the current intended
> extension) a mixture of boolean and tristate values. String or
> numerical values aren't permitted (and iirc they even cause the config
> process to crash). Nevertheless there are a couple of example where
> choosing between individual string or numeric values is intended (but
> needs to be made work with the current infrastructure, meaning that
> one first chooses between boolean values and then selects (or sets
> through default values in prompt-less config options) the intended
> string or numeric value.
> 
> What you want seems much more fundamental a change, and as I
> understand it you really want the name just as a name space
> separation mechanism.
> 
> >This is a mandatory feature before we can do a Kconfig covering all architectures.
> >I guess there are other issues when we do:
> >
> >if X86
> >source foo/bar/Kconfig
> >endif
> >
> >if PPC
> >source foo/bar/Kconfig
> >endif
> >
> >Where we in foo/bar/Kconfig has a choice list.
> 
> That you be done with
> 
> if X86 || PPC
> source foo/bar/Kconfig
> endif

The problem is that the two source happens in different places as they
are part of a menu structure. So the Kconfig files cannot easily be refactored
to use a sinlge source per file.

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