new kconfig goodies

new kconfig goodies

Post by Roman Zippe » Tue, 13 May 2003 15:50:07



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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

new kconfig goodies

Post by Adrian Bun » Tue, 13 May 2003 16:20:17



> Hi,

Hi Roman,

Quote:>...
> 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.

Quote:> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

new kconfig goodies

Post by Dave Jone » Tue, 13 May 2003 16:40:07


 > 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

new kconfig goodies

Post by Geert Uytterhoeve » Tue, 13 May 2003 17:20:19



> 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

--

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

new kconfig goodies

Post by Roman Zippe » Tue, 13 May 2003 17:50:09


Hi,


> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

new kconfig goodies

Post by Roman Zippe » Tue, 13 May 2003 17:50:08


Hi,


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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

new kconfig goodies

Post by Roman Zippe » Tue, 13 May 2003 17:50:12


Hi,


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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

new kconfig goodies

Post by Tomas Szep » Tue, 13 May 2003 18:10:07




>  > 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)") */

--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

new kconfig goodies

Post by Dave Jone » Tue, 13 May 2003 18:10:16


 > > 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

new kconfig goodies

Post by Roman Zippe » Wed, 14 May 2003 00:40:16


Hi,


> 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).

Quote:>  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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

new kconfig goodies

Post by Miles Bade » Wed, 14 May 2003 03:40:12



> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

new kconfig goodies

Post by Miles Bade » Wed, 14 May 2003 03:50:04



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

Quote:> 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?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

new kconfig goodies

Post by Roman Zippe » Wed, 14 May 2003 17:30:22


Hi,


Quote:> > 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

new kconfig goodies

Post by Miles Bade » Wed, 14 May 2003 23:30:12



> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

new kconfig goodies

Post by Roman Zippe » Thu, 15 May 2003 22:00:20


Hi,


> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. drivers/char/Kconfig:640: can't open file "drivers/char/ipmi/Kconfig"

from a bk-pull today,

nirvana:/usr/src/mylinux-2.5# make xconfig
make -f scripts/Makefile.build obj=scripts
make -f scripts/Makefile.build obj=scripts/kconfig scripts/kconfig/qconf
  cat scripts/kconfig/zconf.tab.h_shipped > scripts/kconfig/zconf.tab.h
  gcc -Wp,-MD,scripts/kconfig/.conf.o.d -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer   -c -o scripts/kconfig/conf.o
scripts/kconfig/conf.c
sed < scripts/kconfig/lkc_proto.h > scripts/kconfig/lkc_defs.h
's/P(\([^,]*\),.*/#define \1 (\*\1_p)/'
  gcc -Wp,-MD,scripts/kconfig/.kconfig_load.o.d -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer   -c -o
scripts/kconfig/kconfig_load.o scripts/kconfig/kconfig_load.c
  gcc -Wp,-MD,scripts/kconfig/.mconf.o.d -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer   -c -o scripts/kconfig/mconf.o
scripts/kconfig/mconf.c
/opt/qt//bin/moc -i scripts/kconfig/qconf.h -o scripts/kconfig/qconf.moc
  g++ -Wp,-MD,scripts/kconfig/.qconf.o.d -O2  -I/opt/qt//include  -c -o
scripts/kconfig/qconf.o scripts/kconfig/qconf.cc
  cat scripts/kconfig/zconf.tab.c_shipped > scripts/kconfig/zconf.tab.c
  cat scripts/kconfig/lex.zconf.c_shipped > scripts/kconfig/lex.zconf.c
  gcc -Wp,-MD,scripts/kconfig/.zconf.tab.o.d -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer  -Iscripts/kconfig -fPIC -c -o
scripts/kconfig/zconf.tab.o scripts/kconfig/zconf.tab.c
  gcc  -shared -o scripts/kconfig/libkconfig.so
scripts/kconfig/zconf.tab.o
  g++  -o scripts/kconfig/qconf  scripts/kconfig/kconfig_load.o
scripts/kconfig/qconf.o  -L/opt/qt//lib -Wl,-rpath,/opt/qt//lib -lqt-mt
-ldl
./scripts/kconfig/qconf arch/i386/Kconfig
Xlib:  extension "GLX" missing on display ":0.0".
Xlib:  extension "GLX" missing on display ":0.0".
drivers/char/Kconfig:640: can't open file "drivers/char/ipmi/Kconfig"
make: *** [xconfig] Error 1
nirvana:/usr/src/mylinux-2.5# make oldconfig
make -f scripts/Makefile.build obj=scripts
make -f scripts/Makefile.build obj=scripts/kconfig scripts/kconfig/conf
  gcc  -o scripts/kconfig/conf scripts/kconfig/conf.o
scripts/kconfig/libkconfig.so
./scripts/kconfig/conf -o arch/i386/Kconfig
drivers/char/Kconfig:640: can't open file "drivers/char/ipmi/Kconfig"
make: *** [oldconfig] Error 1

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. kernel set up problem

3. New kconfig: Please add define_*

4. sudo

5. BLISS Archive of CGI and Java goodies

6. Reality Check (re 16450 UART)

7. web page goodies

8. Failure to recognize floppy drive

9. X, DRI, Xinerama, and other linux goodies

10. BLISS Archive of CGI and Java goodies

11. finger goodies?