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

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

Date:	Wed, 16 Jan 2008 13:46:57 +0000
From:	"Jan Beulich" <jbeulich@...ell.com>
To:	"Sam Ravnborg" <sam@...nborg.org>
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

>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

then, I would think (which should be the default anyway if you want a
Kconfig covering all architectures).

>I just wanted to raise this now that you anyway are looking into choice
>related issues.

Jan

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