Hi,
There is a new kconfig patch at
http://www.xs4all.nl/~zippel/lc/patches/kconfig-2.5.69.diff.gz
It adds a few new features, which were requested a few times:
- ability to force the value of a config symbol
- defaults accept now an expression
- easier way to define derived symbols
- support for ranges
BTW this clears my todo list of important features for the kconfig syntax
itself, if you think there is something missing, please tell me now,
otherwise it might have to wait for 2.7. After this I work a bit more on
xconfig and the library interface.
The changes in detail:
1. Working with derived symbols becomes simpler, e.g. this:
config FS_MBCACHE
tristate
depends on EXT2_FS_XATTR || EXT3_FS_XATTR
default y if EXT2_FS=y || EXT3_FS=y
default m if EXT2_FS=m || EXT3_FS=m
can now also be written as:
config FS_MBCACHE
def_tristate EXT2_FS || EXT3_FS
depends on EXT2_FS_XATTR || EXT3_FS_XATTR
There are two new keywords "def_bool" and "def_tristate", which behave
like "default", except that they also set the type of the config symbol.
Defaults also accept expressions now, the result of it will be used as
default (this works of course only with boolean and tristate symbols).
2. There is a new keyword "enable", which can be used to force the value
of another config value, e.g.
config NLS
bool
depends on JOLIET || FAT_FS || NTFS_FS || NCPFS_NLS || SMB_NLS || JFS_FS || CIFS || BEFS_FS
default y
this could be written as:
config NLS
def_bool JOLIET || FAT_FS || NTFS_FS || NCPFS_NLS || SMB_NLS || JFS_FS || CIFS || BEFS_FS
but this is now possible as well:
config NLS
bool
config JOLIET
bool "Microsoft Joliet CDROM extensions"
enable NLS
config FAT_FS
tristate "DOS FAT fs support"
enable NLS
...
This means the information that a file system needs NLS is now specified
with the file system itself and if the file system is selected, so is NLS.
Another example:
config AGP
tristate "/dev/agpgart (AGP Support)" if !GART_IOMMU
default y if GART_IOMMU
this can be changed into:
config AGP
tristate "/dev/agpgart (AGP Support)"
config GART_IOMMU
bool "IOMMU support"
enable AGP
This will cause AGP to be selected if GART_IOMMU is selected.
To better understand how this new feature works, it might help to describe
how a config value is calculated:
config value = (user input && visibility) || reverse dependency
Visibility are the normal dependencies and limit the maximum value a user
can select. Reverse dependencies on the other hand limit the minimum value
a user can select. In above example this means there is a reverse
dependency of GART_IOMMU added to AGP, so that value of AGP cannot be less
than GART_IOMMU anymore.
This feature can be easily abused, so please use it with care, don't use
it to take the choice away from user, e.g. only enable another subsystem
if it would result in compile errors otherwise. If you're not sure, just
ask. To avoid bigger mistakes I finally added the code to check for
recursive dependencies.
3. Finally I added support for ranges, so that this becomes possible:
config LOG_BUF_SHIFT
int "Kernel log buffer size" if DEBUG_KERNEL
range 10 20
...
Right now this is only used to check the direct user input, this means
directly editing .config will ignore the range (please don't rely on this
feature :) ).
bye, Roman
On Mon, May 12, 2003 at 03:39:11PM +0200, Roman Zippel wrote:
> Hi,
Hi Roman,
>...
> BTW this clears my todo list of important features for the kconfig syntax
> itself, if you think there is something missing, please tell me now,
> otherwise it might have to wait for 2.7. After this I work a bit more on
> xconfig and the library interface.
>...
there's one feature I'd like to see (I don't see an easy way to achieve
it currently):
A choice with the possibility to select one or more entries, to support
things like:
Supported processors:
[ ] 386
[ ] 486
[ ] 586
...
It should be possible to select more than one item but selecting zero
items should be illegal.
> bye, Roman
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
On Mon, May 12, 2003 at 03:39:11PM +0200, Roman Zippel wrote:
> config AGP
> tristate "/dev/agpgart (AGP Support)" if !GART_IOMMU
> default y if GART_IOMMU
>
> this can be changed into:
>
> config AGP
> tristate "/dev/agpgart (AGP Support)"
>
> config GART_IOMMU
> bool "IOMMU support"
> enable AGP
>
> This will cause AGP to be selected if GART_IOMMU is selected.
Looks good. However, will this still offer the CONFIG_AGP tristate
in the menu? If IOMMU is on, there must be no way to switch off
the agpgart support on which it depends.
Dave
On Mon, 12 May 2003, Roman Zippel wrote:
> 3. Finally I added support for ranges, so that this becomes possible:
>
> config LOG_BUF_SHIFT
> int "Kernel log buffer size" if DEBUG_KERNEL
> range 10 20
> ...
>
> Right now this is only used to check the direct user input, this means
> directly editing .config will ignore the range (please don't rely on this
> feature :) ).
I hope `make oldconfig' also checks the range? Imagine ranges being changed in
the Kconfig file.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi,
On Mon, 12 May 2003, Dave Jones wrote:
> > config AGP
> > tristate "/dev/agpgart (AGP Support)"
> >
> > config GART_IOMMU
> > bool "IOMMU support"
> > enable AGP
> >
> > This will cause AGP to be selected if GART_IOMMU is selected.
>
> Looks good. However, will this still offer the CONFIG_AGP tristate
> in the menu? If IOMMU is on, there must be no way to switch off
> the agpgart support on which it depends.
Yes, you will see AGP, but you can't change it.
bye, Roman
Hi,
On Mon, 12 May 2003, Adrian Bunk wrote:
> A choice with the possibility to select one or more entries, to support
> things like:
> Supported processors:
> [ ] 386
> [ ] 486
> [ ] 586
> ...
>
> It should be possible to select more than one item but selecting zero
> items should be illegal.
I think that has to wait, supporting this properly would require too many
changes and there are other ways to achieve almost the same.
bye, Roman
Hi,
On Mon, 12 May 2003, Geert Uytterhoeven wrote:
> > Right now this is only used to check the direct user input, this means
> > directly editing .config will ignore the range (please don't rely on this
> > feature :) ).
>
> I hope `make oldconfig' also checks the range? Imagine ranges being changed in
> the Kconfig file.
It's basically the same problem, everything that comes from .config is not
checked yet, but it's easy to change though.
bye, Roman
> [[email protected]]
>
> On Mon, May 12, 2003 at 03:39:11PM +0200, Roman Zippel wrote:
>
> > config AGP
> > tristate "/dev/agpgart (AGP Support)" if !GART_IOMMU
> > default y if GART_IOMMU
> >
> > this can be changed into:
> >
> > config AGP
> > tristate "/dev/agpgart (AGP Support)"
> >
> > config GART_IOMMU
> > bool "IOMMU support"
> > enable AGP
> >
> > This will cause AGP to be selected if GART_IOMMU is selected.
>
> Looks good. However, will this still offer the CONFIG_AGP tristate
> in the menu? If IOMMU is on, there must be no way to switch off
> the agpgart support on which it depends.
Also, will the config system let the user know that their having
enabled a certain option has affected other options (possibly in
different submenus)? As things work now, there's no way to tell
if an option has been switched on "by dependency," so in the above
example, in switching GART_IOMMU off after its switching on has
enabled AGP, the system won't know to disable AGP again. I'm not
convinced this is a nice feature in fact. :) Maybe we just need
something like grayed-out entries with a comment, for instance:
/* [ ] IOMMU support (needs "/dev/agpgard (AGP Support)") */
--
Tomas Szepe <[email protected]>
On Mon, May 12, 2003 at 05:39:45PM +0200, Roman Zippel wrote:
> > Looks good. However, will this still offer the CONFIG_AGP tristate
> > in the menu? If IOMMU is on, there must be no way to switch off
> > the agpgart support on which it depends.
>
> Yes, you will see AGP, but you can't change it.
Perfect!
Dave
Hi,
On Mon, 12 May 2003, Tomas Szepe wrote:
> Also, will the config system let the user know that their having
> enabled a certain option has affected other options (possibly in
> different submenus)?
The user will see that he can't disable certain options.
This is basically the same problem as with other dependencies, if the user
selects an option other options may become visible. There is no direct
information, how the config option depend on each other (except xconfig
offers that as a debug option).
> As things work now, there's no way to tell
> if an option has been switched on "by dependency," so in the above
> example, in switching GART_IOMMU off after its switching on has
> enabled AGP, the system won't know to disable AGP again. I'm not
> convinced this is a nice feature in fact. :) Maybe we just need
> something like grayed-out entries with a comment, for instance:
>
> /* [ ] IOMMU support (needs "/dev/agpgard (AGP Support)") */
Of course the same can be done with normal dependencies, but this new
option offers more flexibility. Important options don't have to be hidden
away behind a lot of dependencies. I'm aware that this can be abused, so I
have to watch a bit how it will be used.
bye, Roman
Roman Zippel <[email protected]> writes:
> 2. There is a new keyword "enable", which can be used to force the value
> of another config value, e.g.
Excellent, excellent, excellent!
I think many patches will now interfere with each other less...
-Miles
--
I'd rather be consing.
Roman Zippel <[email protected]> writes:
> BTW this clears my todo list of important features for the kconfig syntax
> itself, if you think there is something missing, please tell me now,
> otherwise it might have to wait for 2.7.
Hi, I sent the following about kconfig a while ago, but never got an
answer; do you have any comment on it?
Here's the message:
> I have the following two entries in my Kconfig file (arch/v850/Kconfig):
>
> config RTE_CB_MULTI
> bool
> # RTE_CB_NB85E can either have multi ROM support or not, but
> # other platforms (currently only RTE_CB_MA1) require it.
> prompt "Multi monitor ROM support" if RTE_CB_NB85E
> depends RTE_CB
> default y
>
> config RTE_CB_MULTI_DBTRAP
> bool "Pass illegal insn trap / dbtrap to kernel"
> depends RTE_CB_MULTI
> default n
>
> What I expect this to do is to only ask the first question (RTE_CB_MULTI)
> if RTE_CB_NB85E is true and otherwise just assume true -- this part
> seems to work correctly -- but to _always_ ask the second question
> (RTE_CB_MULTI_DBTRAP) as long as its dependencies are true.
>
> However, what happens in practice is that the second question is only
> displayed if the first question is displayed (the resulting actual value
> of RTE_CB_MULTI_DBTRAP is whatever value it had before I entered the
> menuconfig).
>
> So... is this a bug? If not, is there some other way I can have a
> question [a] depend on another question [b], where [b] is optional
> (defaulting to y), but [a] is not?
[I haven't tested this recently, so I suppose it could have silently
been fixed.]
Thanks,
-Miles
--
Would you like fries with that?
Hi,
On 13 May 2003, Miles Bader wrote:
> > I have the following two entries in my Kconfig file (arch/v850/Kconfig):
> >
> > config RTE_CB_MULTI
> > bool
> > # RTE_CB_NB85E can either have multi ROM support or not, but
> > # other platforms (currently only RTE_CB_MA1) require it.
> > prompt "Multi monitor ROM support" if RTE_CB_NB85E
> > depends RTE_CB
> > default y
> >
> > config RTE_CB_MULTI_DBTRAP
> > bool "Pass illegal insn trap / dbtrap to kernel"
> > depends RTE_CB_MULTI
> > default n
> >
> > What I expect this to do is to only ask the first question (RTE_CB_MULTI)
> > if RTE_CB_NB85E is true and otherwise just assume true -- this part
> > seems to work correctly -- but to _always_ ask the second question
> > (RTE_CB_MULTI_DBTRAP) as long as its dependencies are true.
With the new patch this will work. The effect is basically the same as if
you would add "enable RTE_CB_MULTI" to RTE_CB_MA1 - RTE_CB_MULTI is
visible but you cannot change it.
BTW you can remove the "default n" line, this is the default anyway, so
it has no effect.
bye, Roman
On Tue, May 13, 2003 at 05:27:30PM +0200, Roman Zippel wrote:
> With the new patch this will work. The effect is basically the same as if
> you would add "enable RTE_CB_MULTI" to RTE_CB_MA1 - RTE_CB_MULTI is
> visible but you cannot change it.
I see.
BTW, the name `enable' seems to be a misnomer -- `enable' implies that it
forces the depends to be y, but not that it also forces the _value_.
Why not have two:
enable FOO - forces the `depends' value of FOO to y
but it will still prompt
force FOO - forces both the `depends' and value of FOO to y
prompting for FOO is turned off
-Miles
--
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde
Hi,
On Tue, 13 May 2003, Miles Bader wrote:
> BTW, the name `enable' seems to be a misnomer -- `enable' implies that it
> forces the depends to be y, but not that it also forces the _value_.
>
> Why not have two:
>
> enable FOO - forces the `depends' value of FOO to y
> but it will still prompt
> force FOO - forces both the `depends' and value of FOO to y
> prompting for FOO is turned off
I don't really like "force", it's IMO a bit too strong and too unspecific
(although enable is here only a bit better). The first I'd rather call
"visible", but I don't see a need for this and I wouldn't immediately know
how to support this, a config entry can have multiple prompts and every
prompt has its own dependencies, so which one should I enable? It would
probably be easier to enable/force the dependencies so the prompt becomes
visible.
But I'm open to suggestions for a better name, "select" might be a good
alternative. Other ideas? Opinions?
bye, Roman
Roman Zippel <[email protected]> writes:
|> Hi,
|>
|> On Tue, 13 May 2003, Miles Bader wrote:
|>
|> > BTW, the name `enable' seems to be a misnomer -- `enable' implies that it
|> > forces the depends to be y, but not that it also forces the _value_.
|> >
|> > Why not have two:
|> >
|> > enable FOO - forces the `depends' value of FOO to y
|> > but it will still prompt
|> > force FOO - forces both the `depends' and value of FOO to y
|> > prompting for FOO is turned off
|>
|> I don't really like "force", it's IMO a bit too strong and too unspecific
|> (although enable is here only a bit better). The first I'd rather call
|> "visible", but I don't see a need for this and I wouldn't immediately know
|> how to support this, a config entry can have multiple prompts and every
|> prompt has its own dependencies, so which one should I enable? It would
|> probably be easier to enable/force the dependencies so the prompt becomes
|> visible.
|>
|> But I'm open to suggestions for a better name, "select" might be a good
|> alternative. Other ideas? Opinions?
How about "override"?
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 N?rnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Hi,
On Wed, 14 May 2003, Andreas Schwab wrote:
> |> But I'm open to suggestions for a better name, "select" might be a good
> |> alternative. Other ideas? Opinions?
>
> How about "override"?
Hmm, I think it doesn't really fit, it's a bit more than this, e.g. if one
option is set 'm', the other option can still be set to 'm' or 'y'. The
logic is basically "if this option is selected, automatically select this
other option too.", so currently I like "select" best.
bye, Roman
Roman Zippel <[email protected]> writes:
> Hmm, I think it doesn't really fit, it's a bit more than this, e.g. if one
> option is set 'm', the other option can still be set to 'm' or 'y'. The
> logic is basically "if this option is selected, automatically select this
> other option too.", so currently I like "select" best.
How about 'assert'?
Mike
--
I don't need no makeup, I've got real scars -- Tom Waits