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,
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
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?
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
On Thu, 31 Oct 2002 17:03:04 +0100 (CET)
Roman Zippel <[email protected]> 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
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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
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
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/
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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
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/
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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/
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
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/
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
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--
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