[PATCH] new kconfig goodies

[PATCH] new kconfig goodies

[Roman Zippel]

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

Re: [PATCH] new kconfig goodies

[Adrian Bunk]

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

Re: [PATCH] new kconfig goodies

[Dave Jones]

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

Re: [PATCH] new kconfig goodies

[Geert Uytterhoeven]

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 -- geert@linux-m68k.org

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

Re: [PATCH] new kconfig goodies

[Roman Zippel]

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

Re: [PATCH] new kconfig goodies

[Roman Zippel]

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

Re: [PATCH] new kconfig goodies

[Roman Zippel]

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

Re: [PATCH] new kconfig goodies

[Tomas Szepe]

> [davej@codemonkey.org.uk]
> 
> 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 <szepe@pinerecords.com>

Re: [PATCH] new kconfig goodies

[Dave Jones]

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

Re: [PATCH] new kconfig goodies

[Roman Zippel]

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

Re: [PATCH] new kconfig goodies

[Miles Bader]

Roman Zippel <zippel@linux-m68k.org> 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.

Re: [PATCH] new kconfig goodies

[Miles Bader]

Roman Zippel <zippel@linux-m68k.org> 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?

Re: [PATCH] new kconfig goodies

[Roman Zippel]

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

Re: [PATCH] new kconfig goodies

[Miles Bader]

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

Re: [PATCH] new kconfig goodies

[Roman Zippel]

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

Re: [PATCH] new kconfig goodies

[Andreas Schwab]

Roman Zippel <zippel@linux-m68k.org> 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, schwab@suse.de
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."

Re: [PATCH] new kconfig goodies

[Roman Zippel]

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

Re: [PATCH] new kconfig goodies

[Michael Alan Dorman]

Roman Zippel <zippel@linux-m68k.org> 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