Where's the documentation for Kconfig?

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.

Hi,

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

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

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.

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

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

Hi,

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

bye, Roman

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

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 ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Hi,

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

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 ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

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/

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

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

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

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

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

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

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/

Hi,

Why?

bye, Roman

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/

Hi,

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

Hi,

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

Hi,

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

regards, roms.

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

Hi,

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

bye, Roman

I just gave qconf a try in a clone of bk://linux.bkbits.net/linux-2.5 pulled up to [email protected], 2002-11-01 20:51:14-08:00, [email protected]

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

Hi,

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

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

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

Hi,

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

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