Where's the documentation for Kconfig?

Where's the documentation for Kconfig?

[Matthew Wilcox]

I'm just looking over the new arch/parisc/Kconfig trying to make sure that
it got translated correctly, but I can't find any documentation.  Some of
the Kconfig files refer to "the Configure script" -- what Configure
script?  Some of them refer to Documentation/kbuild/config-language.txt
-- which describes the old one.  Most don't tell you where to find
the description.

What's the difference between `help' and `---help---'?
What's the new idiom for define_bool?

-- 
Revolutions do not require corporate support.

Re: Where's the documentation for Kconfig?

[Roman Zippel]

Hi,

On Thu, 31 Oct 2002, Matthew Wilcox wrote:

> I'm just looking over the new arch/parisc/Kconfig trying to make sure that
> it got translated correctly, but I can't find any documentation.

http://www.xs4all.nl/~zippel/lc/

>  Some of
> the Kconfig files refer to "the Configure script" -- what Configure
> script?  Some of them refer to Documentation/kbuild/config-language.txt
> -- which describes the old one.  Most don't tell you where to find
> the description.

The comments are still the same as before and need to be corrected 
manually.

> What's the difference between `help' and `---help---'?

None. Actually you can insert lots of '---' as separators almost anywhere 
you want. The converter used ---help--- for large help texts to separate 
them a bit better from the other options.

> What's the new idiom for define_bool?

Here a small howto for CML1 users.

cml1:
bool/tristate/int/... /prompt/ /symbol/ /word/

kconfig:
config /symbol/
	bool /prompt/
	default /word/

(bool/tristate have now defaults as well.)

cml1:
define_bool /symbol/ /word/

kconfig:
config /symbol/
	bool
	default /word/

cml1:
dep_bool /prompt/ /symbol/ /dep/ ...

kconfig:
config /symbol/
	bool /prompt/
	depends on /dep/=y && ...

cml1:
dep_mbool /prompt/ /symbol/ /dep/ ...
dep_int...

kconfig:
config /symbol/
	bool /prompt/
	depends on /dep/ && ...

cml1:
choice /prompt/ /word/ /word/

kconfig:
choice
	prompt /prompt/
	default /symbol/

config
	....

endchoice

Especially the choice statement became much more powerful. Multiple 
defaults are possible, every choice value can have further dependencies 
and it can be tristate.

Dependencies are very close to the old behaviour with only some small 
differences, e.g. '-a'/'-o' are simply '&&'/'||', "CONFIG_FOO"="y" becomes 
FOO=y and only FOO has the same meaning as in dep_tristate.  Important 
here is that the undefined state is gone and kconfig will soon start 
emit warnings for undefined symbols used in expressions.

bye, Roman

Re: Where's the documentation for Kconfig?

[Christoph Hellwig]

On Thu, Oct 31, 2002 at 03:43:26PM +0100, Roman Zippel wrote:
> Here a small howto for CML1 users.

Could you please update Documentation/kbuild/config-language.txt
based on that?

Re: Where's the documentation for Kconfig?

[Roman Zippel]

Hi,

On Thu, 31 Oct 2002, Christoph Hellwig wrote:

> > Here a small howto for CML1 users.
> 
> Could you please update Documentation/kbuild/config-language.txt
> based on that?

Actually I want to update it based on what's on my home page. I'll do it 
very soon.

bye, Roman

Re: Where's the documentation for Kconfig?

[Rusty Russell]

On Thu, 31 Oct 2002 17:03:04 +0100 (CET)
Roman Zippel <zippel@linux-m68k.org> wrote:

> Hi,
> 
> On Thu, 31 Oct 2002, Christoph Hellwig wrote:
> 
> > > Here a small howto for CML1 users.
> > 
> > Could you please update Documentation/kbuild/config-language.txt
> > based on that?
> 
> Actually I want to update it based on what's on my home page. I'll do it 
> very soon.

Doco is great, and it'd be nice to replace what's there, but I think it's
remarkably easy to use in a monkey-see-monkey-do fashion, which is *really*
good because that's how people will use it.

Plus, I never realized how slow the old "make oldconfig" was.

Thanks Roman!
Rusty.
-- 
   there are those who do and those who hang on and you don't see too
   many doers quoting their contemporaries.  -- Larry McVoy

Re: Where's the documentation for Kconfig?

[Russell King]

On Thu, Oct 31, 2002 at 03:43:26PM +0100, Roman Zippel wrote:
> On Thu, 31 Oct 2002, Matthew Wilcox wrote:
> > I'm just looking over the new arch/parisc/Kconfig trying to make sure that
> > it got translated correctly, but I can't find any documentation.
> 
> http://www.xs4all.nl/~zippel/lc/

Is there a tool to convert _a_ Config.in to a Kconfig?  lkcc doesn't
seem to do it - it wants to do thw hole lot, which isn't very useful
when you've got half a tree that's converted and many Config.in files
that contain updates that aren't in Kconfig.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Where's the documentation for Kconfig?

[Roman Zippel]

Hi,

On Fri, 1 Nov 2002, Russell King wrote:

> Is there a tool to convert _a_ Config.in to a Kconfig?  lkcc doesn't
> seem to do it - it wants to do thw hole lot, which isn't very useful
> when you've got half a tree that's converted and many Config.in files
> that contain updates that aren't in Kconfig.

You could put it into arch/tmp/config.in and do 'lkcc tmp'.
But converting the whole tree is the prefered solution, because lkcc needs 
all the type information of every symbol used in the config file to do a 
good job. The easiest solution is probably to get the 2.5.44 patch from my 
page, generate a diff to your converted 2.5.44 tree and apply this patch 
to 2.5.45. If you send me a 2.5.44 patch of your tree, I can do it for 
you.

bye, Roman

Re: Where's the documentation for Kconfig?

[Russell King]

Ok, next problem.

A "hex" config entry under the old config language used to omit the "0x"
prefix, requiring it to be added by whatever used it.  Kconfig adds the
"0x" prefix, thereby causing errors.

Is this difference intentional?

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Where's the documentation for Kconfig?

[Tom Rini]

On Fri, Nov 01, 2002 at 07:31:12PM +0000, Russell King wrote:
> Ok, next problem.
> 
> A "hex" config entry under the old config language used to omit the "0x"
> prefix, requiring it to be added by whatever used it.  Kconfig adds the
> "0x" prefix, thereby causing errors.
> 
> Is this difference intentional?

I would imagine so since it means you don't have to add '0x' in front of
things anymore (since IIRC define_hex would allow either previously, fun
and hilarity would ensure).

On a related question, can we now have 'UL', etc in a hex statement /
question?

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: Where's the documentation for Kconfig?

[Russell King]

On Fri, Nov 01, 2002 at 01:30:33PM -0700, Tom Rini wrote:
> On a related question, can we now have 'UL', etc in a hex statement /
> question?

No thanks - that'll stop it being used in linker scripts.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Where's the documentation for Kconfig?

[Tom Rini]

On Fri, Nov 01, 2002 at 08:35:46PM +0000, Russell King wrote:
> On Fri, Nov 01, 2002 at 01:30:33PM -0700, Tom Rini wrote:
> > On a related question, can we now have 'UL', etc in a hex statement /
> > question?
> 
> No thanks - that'll stop it being used in linker scripts.

How, if it's not used for a value which a linker script cares about?

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: Where's the documentation for Kconfig?

[Russell King]

On Fri, Nov 01, 2002 at 01:42:25PM -0700, Tom Rini wrote:
> On Fri, Nov 01, 2002 at 08:35:46PM +0000, Russell King wrote:
> > On Fri, Nov 01, 2002 at 01:30:33PM -0700, Tom Rini wrote:
> > > On a related question, can we now have 'UL', etc in a hex statement /
> > > question?
> > 
> > No thanks - that'll stop it being used in linker scripts.
> 
> How, if it's not used for a value which a linker script cares about?

Hmm, maybe I'm misunderstanding you.  Where do you want "UL" to appear
in relation to a "hex" statement?

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Where's the documentation for Kconfig?

[Tom Rini]

On Fri, Nov 01, 2002 at 08:46:43PM +0000, Russell King wrote:
> On Fri, Nov 01, 2002 at 01:42:25PM -0700, Tom Rini wrote:
> > On Fri, Nov 01, 2002 at 08:35:46PM +0000, Russell King wrote:
> > > On Fri, Nov 01, 2002 at 01:30:33PM -0700, Tom Rini wrote:
> > > > On a related question, can we now have 'UL', etc in a hex statement /
> > > > question?
> > > 
> > > No thanks - that'll stop it being used in linker scripts.
> > 
> > How, if it's not used for a value which a linker script cares about?
> 
> Hmm, maybe I'm misunderstanding you.  Where do you want "UL" to appear
> in relation to a "hex" statement?

I want both of these statements to be legal:

config HEXVAL_A
	hex
	depends on FOO || BAR
	default "0x12345678"

config HEXVAL_B
	hex
	depends on BAZ
	default "0x12345678UL"

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: Where's the documentation for Kconfig?

[Roman Zippel]

Hi,

On Fri, 1 Nov 2002, Tom Rini wrote:

> I want both of these statements to be legal:
> 
> config HEXVAL_B
> 	hex
> 	depends on BAZ
> 	default "0x12345678UL"

Why?

bye, Roman

Re: Where's the documentation for Kconfig?

[Tom Rini]

On Sat, Nov 02, 2002 at 12:52:05AM +0100, Roman Zippel wrote:
> Hi,
> 
> On Fri, 1 Nov 2002, Tom Rini wrote:
> 
> > I want both of these statements to be legal:
> > 
> > config HEXVAL_B
> > 	hex
> > 	depends on BAZ
> > 	default "0x12345678UL"
> 
> Why?

Consistency with values?  It's not needed, but in somplaces we had:
#define FOO 0x12345678UL,
which was replaced with
#define FOO CONFIG_BAR_VALUE

So for consistency (and only that really, so if it's hard just say No)
I'd like to be able to put back the 'UL' / 'L'

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: Where's the documentation for Kconfig?

[Roman Zippel]

Hi,

On Fri, 1 Nov 2002, Tom Rini wrote:

> Consistency with values?  It's not needed, but in somplaces we had:
> #define FOO 0x12345678UL,
> which was replaced with
> #define FOO CONFIG_BAR_VALUE
> 
> So for consistency (and only that really, so if it's hard just say No)
> I'd like to be able to put back the 'UL' / 'L'

It would add more complexity than it gives us it. I would implement it if 
it would help avoiding helping complexity somewhere else.

bye, Roman

Re: Where's the documentation for Kconfig?

[Roman Zippel]

Hi,

On Fri, 1 Nov 2002, Russell King wrote:

> Ok, next problem.
> 
> A "hex" config entry under the old config language used to omit the "0x"
> prefix, requiring it to be added by whatever used it.  Kconfig adds the
> "0x" prefix, thereby causing errors.
> 
> Is this difference intentional?

No, but looking at it, I think it's better to fix the few users and to 
keep it common instead. Is there anything that needs the numbers without 
the prefix?

bye, Roman

Re: Kconfig (qt) -> Gconfig (gtk+)

[Romain Lievin]

Hi,

On Sat, Nov 02, 2002 at 12:59:22PM +0100, Roman Zippel wrote:
> Hi,
> 
> On Wed, 26 Jun 2002, Romain Lievin wrote:
> 
> > I noticed there is a new configuration tool written in qt for replacing the tcl/tk one.
> > 
> > Is there any plan to write a similar configuration tool in GTK+ ? 
> > I will be interested in writing a such one...
> 
> I'm not planning to do it myself, so go ahead. If you have any questions, 
> just ask.

ok, let's go !
BTW, is there any doc about your library ?

> 
> bye, Roman
> 
> 

regards, roms.
-- 
Romain Lievin, aka 'roms'  	<roms@lpg.ticalc.org>
Web site 			<http://lpg.ticalc.org/prj_tilp>
"Linux, y'a moins bien mais c'est plus cher !"

Re: Kconfig (qt) -> Gconfig (gtk+)

[Roman Zippel]

Hi,

On Sat, 2 Nov 2002, Romain Lievin wrote:

> > I'm not planning to do it myself, so go ahead. If you have any questions, 
> > just ask.
> 
> ok, let's go !
> BTW, is there any doc about your library ?

Not really (yet), but you have several examples and most functions should 
be self-explanatory.

bye, Roman

qconf buglet

[James H. Cloos Jr.]

I just gave qconf a try in a clone of bk://linux.bkbits.net/linux-2.5
pulled up to ChangeSet@1.872, 2002-11-01 20:51:14-08:00, torvalds@home.transmeta.com

Fonts did not display at all until I ran it with QT_XFT=0.

It may be reasonable to force that.

Box started as suse 7.3; has qt-2.3.2 and has xft1 from
fontconfig-1.0.1.  ldd(1) on qconf shows:

        libqt-mt.so.2 => /usr/lib/qt2/lib/libqt-mt.so.2 (0x40016000)
        libdl.so.2 => /lib/libdl.so.2 (0x404f3000)
        libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x404f7000)
        libm.so.6 => /lib/libm.so.6 (0x40544000)
        libc.so.6 => /lib/libc.so.6 (0x40566000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x4068c000)
        libGLU.so.1 => /usr/lib/libGLU.so.1 (0x406a3000)
        libGL.so.1 => /usr/lib/libGL.so.1 (0x4072c000)
        libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40795000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x407ab000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x407b9000)
        libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40879000)
        libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40883000)
        libXft.so.1 => /usr/X11R6/lib/libXft.so.1 (0x4089b000)
        libpng.so.2 => /usr/lib/libpng.so.2 (0x408a9000)
        libz.so.1 => /lib/libz.so.1 (0x408db000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x408ea000)
        libmng.so.1 => /usr/lib/libmng.so.1 (0x40909000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
        libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4094a000)
        libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x40997000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x4099e000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x409c4000)
        liblcms.so.1 => /usr/lib/liblcms.so.1 (0x40a13000)
        libexpat.so.0 => /usr/lib/libexpat.so.0 (0x40a24000)

-JimC

Re: qconf buglet

[Roman Zippel]

Hi,

On 2 Nov 2002, James H. Cloos Jr. wrote:

> Fonts did not display at all until I ran it with QT_XFT=0.
> 
> It may be reasonable to force that.

How do other qt apps behave? I'm not doing anything special with fonts, so 
I don't see reason why this should be needed.

bye, Roman

Re: qconf buglet

[James H. Cloos Jr.]

>>>>> "Roman" == Roman Zippel <zippel@linux-m68k.org> writes:

Roman> How do other qt apps behave? I'm not doing anything special
Roman> with fonts, so I don't see reason why this should be needed.

Ack.  I did further debugging with XFT_DEBUG and discovered that
"Helvetica" was getting matched to a rogue font.  I added a rule to
fonts.conf to force Helvetica to Arial and it now works.

I should have tested with XFT_DEBUG=1 before posting....

-JimC

Re: Where's the documentation for Kconfig?

[Erik Andersen]

On Thu Oct 31, 2002 at 03:43:26PM +0100, Roman Zippel wrote:
> kconfig:
> config /symbol/
> 	bool /prompt/
> 	default /word/

Suppose at some time we wished to move things like architecture
specific CFLAGS into Kconfig.  It would be implemented as a
"string" object and would look something like:

config CPU_CFLAGS
        string
        default "-march=i386" if M386
        default "-march=i486" if M486
        default "-march=i586" if M586
        default "-march=i686 -malign-functions=4" if MK7

This is terribly simplified, but I think you get the idea.
Suppose someone selects MK7.  The resulting .config file
would then have:

    CONFIG_CPU_CFLAGS="-march=i686 -malign-functions=4"

Since this file is sourced into the Makefile, we could then
append CONFIG_CPU_CFLAGS onto the CFLAGS.  This would also
be kindof cool, since we could add in Makefile macros into the
strings and they would actually be evaluated...

So for the K7 case, we could expand it to something much more
sneaky later on, something like:
    default "$(call check_gcc,-march=athlon,-march=i686 -malign-functions=4)" if MK7
and the check_gcc macro could be correctly evaluated by make.
Neat stuff.  (Such a check_gcc macro does not yet exist in the 
kernel Makefiles, but surely will sometime).

Ok, everything looks fine so far.  But now we see a problem...

String objects always contain quotes (") around them.  So when
included into a Makefile, we would end up with something like:

    gcc -Wall "-march=i686 -malign-functions=4" foo.c -o bar

or similar being run.  Because the entire string object value is
quoted, gcc will try to set arch="i686 -malign-functions=4" and
will blow up.  Not what we want at all...  Dropping the quotes
from the .config file would work, but would probably screw up
other things that need the quotes to work properly.  Creating a
new "unquoted_string" data type would work nicely.  

Any interest in adding an "unquoted_string" data type ?  I dunno
if such a data type is anything you care about, but I can imagine
cool things being done with it, such as the above.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: Where's the documentation for Kconfig?

[Roman Zippel]

Hi,

On Sat, 2 Nov 2002, Erik Andersen wrote:

> On Thu Oct 31, 2002 at 03:43:26PM +0100, Roman Zippel wrote:
> > kconfig:
> > config /symbol/
> > 	bool /prompt/
> > 	default /word/
> 
> Suppose at some time we wished to move things like architecture
> specific CFLAGS into Kconfig.  It would be implemented as a
> "string" object and would look something like:
> 
> config CPU_CFLAGS
>         string
>         default "-march=i386" if M386
>         default "-march=i486" if M486
>         default "-march=i586" if M586
>         default "-march=i686 -malign-functions=4" if MK7

It's possible, but I don't think we will start in the arch part. More 
interesting would be driver entries like:

driver foo
	tristate "foo support"
	depends on BAR
	source foo.c

part of this could also be:

	cflags "..." [if ...]


> So for the K7 case, we could expand it to something much more
> sneaky later on, something like:
>     default "$(call check_gcc,-march=athlon,-march=i686 -malign-functions=4)" if MK7
> and the check_gcc macro could be correctly evaluated by make.
> Neat stuff.  (Such a check_gcc macro does not yet exist in the 
> kernel Makefiles, but surely will sometime).

Having make specific macros in the configuration is not really a good 
idea. Such tests should rather be done by a shell script and its output 
would be imported into the build system.

bye, Roman