LinuxLists.cc - Linux 2.4.20-pre1

[permalink] [raw]

Subject: Re: Linux 2.4.20-pre1

Alan Cox <[email protected]> writes:

> - Remove mess where x86_64 sticks its arse in all sorts of
> config files and makes a mess of it. Other ports done because
> the result sucks, x86_64 shouldnt either

Can you explain this further. How else do you propose to get rid of
unmaintained-and-absolutely-hopeless-on-64bit drivers in the configuration?
I definitely do not want to get bug reports about these not working on x86-64.

If you think CONFIG_X86_64 is too ugly, perhaps an generic CONFIG_64BIT would
be preferable for you? I personally would prefer CONFIG_UNMAINTAINED_AND_BROKEN and telling users they are on their own when they enable it, but that is
probably just me.

> - Drop utterly bogus change todrivers/sound/Config.in

Given that one was bogus. Must have been a merge mistake on my part.

-Andi

2002-08-07 10:27:39

by Alan

[permalink] [raw]

Subject: Re: Linux 2.4.20-pre1

On Wed, 2002-08-07 at 11:01, Andi Kleen wrote:
> Can you explain this further. How else do you propose to get rid of
> unmaintained-and-absolutely-hopeless-on-64bit drivers in the configuration?
> I definitely do not want to get bug reports about these not working on x86-64.

I don't want a tree where every driver has seventeen lines of if IBM and
not 64bit || parisc || x86 || !x86_64 || ia64) && (!wednesdayafternoon)

Its *unmaintainable*.

The sparc64 people don't do it, the mips people don't do it, the ia64
people don't do it, wtf should you get to fill config.in with crap

The _ISA stuff makes sense, thats sensible, but the rest - when people
moan we tell em to fix the drivers.

2002-08-07 10:38:18

[permalink] [raw]

Subject: 64bit clean drivers was Re: Linux 2.4.20-pre1

On Wed, Aug 07, 2002 at 12:50:43PM +0100, Alan Cox wrote:
> On Wed, 2002-08-07 at 11:01, Andi Kleen wrote:
> > Can you explain this further. How else do you propose to get rid of
> > unmaintained-and-absolutely-hopeless-on-64bit drivers in the configuration?
> > I definitely do not want to get bug reports about these not working on x86-64.
>
> I don't want a tree where every driver has seventeen lines of if IBM and
> not 64bit || parisc || x86 || !x86_64 || ia64) && (!wednesdayafternoon)
>
> Its *unmaintainable*.

I don't see why it is unmaintainable. What is so bad with these ifs?
64bit cleanness is just another dependency, nothing magic and fundamentally
hard.

I admit it is a bit ugly to hardcode CONFIG_X86_64 here, I would actually
prefer an generic CONFIG_64BIT

At least for i386 it should make no difference at all.

If you object to the ifdefs I can turn it into
dep_tristate ... $CONFIG_X86_32 (or CONFIG_I386 and add this)

(unfortunately there is no dep_tristate ... !$CONFIG_64BIT)
Alternatively CONFIG_NO_64BIT to work around this issue.

>
> The sparc64 people don't do it, the mips people don't do it, the ia64
> people don't do it, wtf should you get to fill config.in with crap

The main reason I'm doing this is that unlike IA64,alpha,mips (sorry no
offense to these ports) x86-64 is aimed at the mass market. I will
not invoke the A..T... word, but having a configuration where a good
chunk of the drivers do not work is just not acceptable for x86-64 where
even non kernel hackers will likely recompile the kernels. I tried
to fix it for some of the drivers but some are obviously hopeless without
major work.

> The _ISA stuff makes sense, thats sensible, but the rest - when people
> moan we tell em to fix the drivers.

I don't think it is very nice. Some of these actually compile, just with
thousands of warnings, but will oops very quickly likely after first load.
I prefer to disable them. That is much nicer to the user.

-Andi

2002-08-07 11:00:43

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

On Wed, Aug 07, 2002 at 01:16:48PM +0100, Alan Cox wrote:
> On Wed, 2002-08-07 at 11:41, Andi Kleen wrote:
> > I don't see why it is unmaintainable. What is so bad with these ifs?
> > 64bit cleanness is just another dependency, nothing magic and fundamentally
> > hard.
>
> Lets take I2O block the if rule would
>
> if [ $CONFIG_X86 = "y" -a $CONFIG_X86_64 != "y" ]
> dep_bool ...

dep_bool .... $CONFIG_X86_32

Would that be acceptable for you? (ok that would not cover ppc32 for
example, but they may have other issues with the driver)

> The actual rule being if 32bit little endian || 64bit little endian with
> kernel memory objects always below 4Gb and having PCI bus

I don't see it as a that big problem. It just needs a few more negated
generic symbols defined (e.g. CONFIG_32BIT CONFIG_4GB_ONLY
CONFIG_LITTLE_ENDIAN), then it could be easily expressed with dep_... even
in the traditional configuration language. I also don't think it would
be particularly unmaintainable to have these things in Config.

>
>
> Thats just one non too complicated driver. CML1 can't handle this
> scalably, maybe CML2 could have.
>
> Secondly you actually want people to discover stuff doesn't work so you
> can persuade them to go and fix it. Stick up a 'Good/Probably

They will discover it when they don't find a driver for an device and
can then find the disabled configuration and look into fixing it
(for someone able to fix the driver checking the configuration should
be trivial)

In my opinion it is just not acceptable when the enable the driver by
mistake or load the wrong module and it crashes.

> Ok/Bad/Hopeless' driver listing on x86_64.org, then once Hammer becomes
> in general use post it to the janitor list now and then

That will be likely done anyways, but it is not enough.

-Andi

2002-08-07 11:07:12

by Alan Cox

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

> dep_bool .... $CONFIG_X86_32
>
> Would that be acceptable for you? (ok that would not cover ppc32 for
> example, but they may have other issues with the driver)

dep_bool doesnt have negations, bracketing or or operations. Thats why
CML1 can't handle it but CML2 probably could have

> They will discover it when they don't find a driver for an device and
> can then find the disabled configuration and look into fixing it
> (for someone able to fix the driver checking the configuration should
> be trivial)

No they'll mail you asking where it has gone

> In my opinion it is just not acceptable when the enable the driver by
> mistake or load the wrong module and it crashes.

Thats a packaging issue for distributed prebuilt kernel trees. Also crashes
are the only way you are going to find out what needs fixing, who wants to
fix it and the like

2002-08-07 11:14:50

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

On Wed, Aug 07, 2002 at 07:10:36AM -0400, Alan Cox wrote:
> > dep_bool .... $CONFIG_X86_32
> >
> > Would that be acceptable for you? (ok that would not cover ppc32 for
> > example, but they may have other issues with the driver)
>
> dep_bool doesnt have negations, bracketing or or operations. Thats why
> CML1 can't handle it but CML2 probably could have

But you can always define negative symbols (CONFIG_4GB CONFIG_32BIT CONFIG_LITTLE_ENDIAN,
no need for !CONFIG_BIG_ENDIAN). I don't see how or should be
needed with careful chosing of symbols.

>
> > They will discover it when they don't find a driver for an device and
> > can then find the disabled configuration and look into fixing it
> > (for someone able to fix the driver checking the configuration should
> > be trivial)
>
> No they'll mail you asking where it has gone

That's fine too.

>
> > In my opinion it is just not acceptable when the enable the driver by
> > mistake or load the wrong module and it crashes.
>
> Thats a packaging issue for distributed prebuilt kernel trees. Also crashes
> are the only way you are going to find out what needs fixing, who wants to
> fix it and the like

I disagree. In my opinion such low standards on the kernel configuration
are not acceptable. Things that 100% will not work should not be
visible.

-Andi

2002-08-07 10:53:49

by Alan

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

On Wed, 2002-08-07 at 11:41, Andi Kleen wrote:
> I don't see why it is unmaintainable. What is so bad with these ifs?
> 64bit cleanness is just another dependency, nothing magic and fundamentally
> hard.

Lets take I2O block the if rule would

if [ $CONFIG_X86 = "y" -a $CONFIG_X86_64 != "y" ]
dep_bool ...
fi
if [ $CONFIG_ALPHA = "y" && other conditions ...]
dep_bool ...
fi

and so on

The actual rule being if 32bit little endian || 64bit little endian with
kernel memory objects always below 4Gb and having PCI bus

Thats just one non too complicated driver. CML1 can't handle this
scalably, maybe CML2 could have.

Secondly you actually want people to discover stuff doesn't work so you
can persuade them to go and fix it. Stick up a 'Good/Probably
Ok/Bad/Hopeless' driver listing on x86_64.org, then once Hammer becomes
in general use post it to the janitor list now and then

Alan

2002-08-07 11:48:39

by Alan Cox

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

> > Thats a packaging issue for distributed prebuilt kernel trees. Also crashes
> > are the only way you are going to find out what needs fixing, who wants to
> > fix it and the like
>
> I disagree. In my opinion such low standards on the kernel configuration
> are not acceptable. Things that 100% will not work should not be
> visible.

Time to chmod 0 the v2.5 directory.

In a perfect would I'd be able to have config_experimental let me pick all
the stuff not tested on x86_64. To do that sanely we have to fix the
configuration language otherwise it will just never be maintainable and
we will spend the rest of 2.4 haunted by "Why has xyz vanished on Alpha
in 2.4.21"

2002-08-07 12:03:11

by Alan

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

On Wed, 2002-08-07 at 12:56, Andi Kleen wrote:
> Can you please shortly explain what will not be maintainable with my
> proposal?

I already have - all the ifs and conditions in the Config.in files

If you think you can do it all nicely with dep_ and not if then prove me
wrong. I'd actually like to see a working clean implementation because I
agree about the problem, I'm dubious that the cure right now is better
than the disease

2002-08-07 11:53:09

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

> In a perfect would I'd be able to have config_experimental let me pick all
> the stuff not tested on x86_64. To do that sanely we have to fix the
> configuration language otherwise it will just never be maintainable and
> we will spend the rest of 2.4 haunted by "Why has xyz vanished on Alpha
> in 2.4.21"

I severly doubt this will a problem. If you look at the drivers that
I marked this way on x86-64 I will bet some beer that they never worked
(some not even compiled) on alpha. Worrying about a userbase of drivers
who have never worked does not seem to be very useful. It definitely would
not be a regression at least.

Can you please shortly explain what will not be maintainable with my
proposal?

-Andi

2002-08-07 16:25:12

by Jeff Garzik

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

Alan Cox wrote:
> On Wed, 2002-08-07 at 12:56, Andi Kleen wrote:
>
>>Can you please shortly explain what will not be maintainable with my
>>proposal?

> If you think you can do it all nicely with dep_ and not if then prove me
> wrong. I'd actually like to see a working clean implementation because I
> agree about the problem, I'm dubious that the cure right now is better
> than the disease

What I did in the past for alpha was go through source and add something
like

#if BITS_PER_LONG != 32
#error this file is broken for 64-bits
#endif

2002-08-07 17:28:07

by Thunder from the hill

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

Hi,

On Wed, 7 Aug 2002, Andi Kleen wrote:
> Alternatively CONFIG_NO_64BIT to work around this issue.

Please don't do this. This way leads to madness when 96/128 bit or
whatever !64 bit comes. (And I can confirm it's cool.) Don't you say
"well" here, I remember being f*cked up when we doubled the bit rate once
on another system. (It was from 4 to 8 bits, actually. Nice time.)

Hardly ANYTHING will be !CONFIG_NO_64BIT.

Thunder
--
.-../../-./..-/-..- .-./..-/.-.././.../.-.-.-

2002-08-08 15:57:11

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

[Andi Kleen]
> I don't see why it is unmaintainable. What is so bad with these ifs?
> 64bit cleanness is just another dependency, nothing magic and fundamentally
> hard.
[...]
> (unfortunately there is no dep_tristate ... !$CONFIG_64BIT)
> Alternatively CONFIG_NO_64BIT to work around this issue.

The real solution (imo) is to add !$CONFIG_FOO support to the config
language. Fortunately this is quite easy. What do you people think?
I didn't do xconfig or config-language.txt but I can if desired.

Tested lightly with ash (not bash)..

Peter

diff -u'rNx*~' 2.4.20pre1/scripts/Configure 2.4.20pre1p/scripts/Configure
--- 2.4.20pre1/scripts/Configure 2001-07-02 15:56:40.000000000 -0500
+++ 2.4.20pre1p/scripts/Configure 2002-08-08 09:55:31.000000000 -0500
@@ -48,6 +48,9 @@
#
# 24 January 1999, Michael Elizabeth Chastain, <[email protected]>
# - Improve the exit message (Jeff Ronne).
+#
+# 7 Aug 2002, Peter Samuelson, <[email protected]>
+# - allow negation (!$CONFIG_FOO) for dependencies in dep_* functions

#
# Make sure we're really running bash.
@@ -250,7 +253,7 @@
shift 2
while [ $# -gt 0 ]; do
case "$1" in
- n)
+ n | !y | !m)
define_tristate "$var" "n"
return
;;
@@ -301,7 +304,7 @@
shift 2
while [ $# -gt 0 ]; do
case "$1" in
- m | n)
+ m | n | !y | !m)
define_bool "$var" "n"
return
;;
@@ -318,7 +321,7 @@
shift 2
while [ $# -gt 0 ]; do
case "$1" in
- n)
+ n | !y | !m)
define_bool "$var" "n"
return
;;
diff -u'rNx*~' 2.4.20pre1/scripts/Menuconfig 2.4.20pre1p/scripts/Menuconfig
--- 2.4.20pre1/scripts/Menuconfig 2002-06-14 15:09:40.000000000 -0500
+++ 2.4.20pre1p/scripts/Menuconfig 2002-08-08 09:55:32.000000000 -0500
@@ -77,8 +77,9 @@
# 12 November 2001, Keith Owens <[email protected]>
# Escape double quotes on eval so the quotes are still there on the second
# evaluation, required to handle strings with special characters.
-#
-
+#
+# 7 Aug 2002, Peter Samuelson <[email protected]>
+# Allow negation (!$CONFIG_FOO) for dependencies in dep_* functions

#
# Change this to TRUE if you prefer all kernel options listed
@@ -219,7 +220,7 @@
dep=y
shift 2
while [ $# -gt 0 ]; do
- if [ "$1" = y ]; then
+ if [ "$1" = y -o "$1" = !n ]; then
shift
elif [ "$1" = m ]; then
dep=m
@@ -248,7 +249,7 @@
dep=y
shift 2
while [ $# -gt 0 ]; do
- if [ "$1" = y ]; then
+ if [ "$1" = y -o "$1" = !n ]; then
shift
else
dep=n
@@ -268,7 +269,7 @@
dep=y
shift 2
while [ $# -gt 0 ]; do
- if [ "$1" = y -o "$1" = m ]; then
+ if [ "$1" = y -o "$1" = m -o "$1" = !n ]; then
shift
else
dep=n
@@ -1089,7 +1090,7 @@
var="$2"
shift 2
while [ $# -gt 0 ]; do
- if [ "$1" = y ]; then
+ if [ "$1" = y -o "$1" = !n ]; then
shift
elif [ "$1" = m -a "$x" != n ]; then
x=m; shift
@@ -1105,7 +1106,7 @@
var="$2"
shift 2
while [ $# -gt 0 ]; do
- if [ "$1" = y ]; then
+ if [ "$1" = y -o "$1" = !n ]; then
shift
else
x=n; shift $#
@@ -1119,7 +1120,7 @@
var="$2"
shift 2
while [ $# -gt 0 ]; do
- if [ "$1" = y -o "$1" = m ]; then
+ if [ "$1" = y -o "$1" = m -o "$1" = !n ]; then
shift
else
x=n; shift $#

2002-08-08 16:45:38

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

On Thu, 8 Aug 2002, Peter Samuelson wrote:

> [Andi Kleen]
> > I don't see why it is unmaintainable. What is so bad with these ifs?
> > 64bit cleanness is just another dependency, nothing magic and fundamentally
> > hard.
> [...]
> > (unfortunately there is no dep_tristate ... !$CONFIG_64BIT)
> > Alternatively CONFIG_NO_64BIT to work around this issue.
>
> The real solution (imo) is to add !$CONFIG_FOO support to the config
> language. Fortunately this is quite easy. What do you people think?
> I didn't do xconfig or config-language.txt but I can if desired.

As you're hacking Configure anyway, what about "fixing"

dep_tristate ' ..' CONFIG_FOO $CONFIG_BAR,

which doesn't work as expected when CONFIG_BAR is not set (as opposed to
"n"), to consider an unset CONFIG_BAR equivalent to "n" in this case?

(The rather hacky way I'd imagine to do so is to look at all used
$CONFIG_* in a Config.in file before sourcing it and setting them to "n")

--Kai

2002-08-08 17:33:55

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

[Kai Germaschewski]
> As you're hacking Configure anyway, what about "fixing"
>
> dep_tristate ' ..' CONFIG_FOO $CONFIG_BAR,

I've thought about that many times. I think the cleanest solution is
to deprecate the '$' entirely:

dep_tristate ' ..' CONFIG_FOO CONFIG_BAR

and, while we're at it, deprecate the 'dep_' prefix as well - can't
"tristate" and "bool" unambiguously handle this?

I think the above can be done quite easily with a bit of 'eval' work
(which *will* slow down 'make *config' ... but do we care?)
Supporting the old syntax simultaneously should not be hard either.
I'm just not sure whether or not it's appropriate for 2.4.20. It *is*
easily testable stuff, but....

And I haven't looked at xconfig. (I don't usually even run X.)
xconfig *does* do static parsing, and is thus superior to Configure
and Menuconfig, but the whole method of "translate Config.in into TCL
then execute it" makes it (imo) really hard to hack on.

Let me see if I can find time to roll a patch sometime today..

Peter

2002-08-08 19:20:14

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

Hi,

On Thu, 8 Aug 2002, Peter Samuelson wrote:

> The real solution (imo) is to add !$CONFIG_FOO support to the config
> language. Fortunately this is quite easy. What do you people think?
> I didn't do xconfig or config-language.txt but I can if desired.

I think it would help a lot if you first update the latter and somehow
describe what the negation in this context is supposed to mean.

bye, Roman

2002-08-08 19:59:35

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

On Thu, Aug 08, 2002 at 09:23:30PM +0200, Roman Zippel wrote:
> Hi,
>
> On Thu, 8 Aug 2002, Peter Samuelson wrote:
>
> > The real solution (imo) is to add !$CONFIG_FOO support to the config
> > language. Fortunately this is quite easy. What do you people think?
> > I didn't do xconfig or config-language.txt but I can if desired.
>
> I think it would help a lot if you first update the latter and somehow
> describe what the negation in this context is supposed to mean.

dependency is met when the symbol is not defined.

What's the problem with the definition ?

-Andi

2002-08-08 20:15:37

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

Hi,

On Thu, 8 Aug 2002, Andi Kleen wrote:

> > > The real solution (imo) is to add !$CONFIG_FOO support to the config
> > > language. Fortunately this is quite easy. What do you people think?
> > > I didn't do xconfig or config-language.txt but I can if desired.
> >
> > I think it would help a lot if you first update the latter and somehow
> > describe what the negation in this context is supposed to mean.
>
> dependency is met when the symbol is not defined.
>
> What's the problem with the definition ?

Boolean is simple, what about tristate symbols? How does it modify the
input range?

bye, Roman

2002-08-08 20:33:19

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

On Thu, Aug 08, 2002 at 10:19:05PM +0200, Roman Zippel wrote:
> Hi,
>
> On Thu, 8 Aug 2002, Andi Kleen wrote:
>
> > > > The real solution (imo) is to add !$CONFIG_FOO support to the config
> > > > language. Fortunately this is quite easy. What do you people think?
> > > > I didn't do xconfig or config-language.txt but I can if desired.
> > >
> > > I think it would help a lot if you first update the latter and somehow
> > > describe what the negation in this context is supposed to mean.
> >
> > dependency is met when the symbol is not defined.
> >
> > What's the problem with the definition ?
>
> Boolean is simple, what about tristate symbols? How does it modify the
> input range?

It doesn't. We just want a low tech simple solution, not a great new theoretic
building.

-Andi

2002-08-08 20:47:49

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

Hi,

On Thu, 8 Aug 2002, Andi Kleen wrote:

> > Boolean is simple, what about tristate symbols? How does it modify the
> > input range?
>
> It doesn't. We just want a low tech simple solution, not a great new theoretic
> building.

But even a simple solution is worth an explanation, isn't it?

bye, Roman

2002-08-08 23:54:14

by Thunder from the hill

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

Hi,

On Thu, 8 Aug 2002, Kai Germaschewski wrote:
> As you're hacking Configure anyway, what about "fixing"
>
> dep_tristate ' ..' CONFIG_FOO $CONFIG_BAR,
>
> which doesn't work as expected when CONFIG_BAR is not set (as opposed to
> "n"), to consider an unset CONFIG_BAR equivalent to "n" in this case?
>
> (The rather hacky way I'd imagine to do so is to look at all used
> $CONFIG_* in a Config.in file before sourcing it and setting them to "n")

Hyphenation might help you to see that there has actually been
something...

Thunder
--
.-../../-./..-/-..- .-./..-/.-.././.../.-.-.-

2002-08-09 00:04:39

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

[Andi Kleen]
> > dependency is met when the symbol is not defined.

Right.

[Roman Zippel]
> Boolean is simple, what about tristate symbols? How does it modify
> the input range?

!y == n
!m == n
!n == y

To me these are the only semantics that make any sense. Certainly if
it goes in the kernel it needs to be added to config-language.txt.

(Note: these are only small changes, but thanks to word-wrapping...)

--- 2.4.20pre1/Documentation/kbuild/config-language.txt 2002-02-25 13:37:51.000000000 -0600
+++ 2.4.20pre1p/Documentation/kbuild/config-language.txt 2002-08-08 12:39:36.000000000 -0500
@@ -85,7 +85,9 @@
making one massive dependency on include/linux/autoconf.h.

A /dep/ is a dependency. Syntactically, it is a /word/. At run
- time, a /dep/ must evaluate to "y", "m", "n", or "".
+ time, a /dep/ must evaluate to "y", "!y", "m", "!m", "n", "!n",
+ "", or "!". The !-prefixed forms have a negated sense: "!y" and
+ "!m" are equivalent to "n"; "!n" and "!" are equivalent to "y".

An /expr/ is a bash-like expression using the operators
'=', '!=', '-a', '-o', and '!'.
@@ -439,12 +441,12 @@
=== dep_bool /prompt/ /symbol/ /dep/ ...

This verb evaluates all of the dependencies in the dependency list.
-Any dependency which has a value of "y" does not restrict the input
-range. Any dependency which has an empty value is ignored.
-Any dependency which has a value of "n", or which has some other value,
-(like "m") restricts the input range to "n". Quoting dependencies is not
-allowed. Using dependencies with an empty value possible is not
-recommended. See also dep_mbool below.
+Any dependency which has a value of "y", "!n" or "!" does not restrict
+the input range. Any dependency which has an empty value is ignored.
+Any dependency which has a value of "n", or which has some other
+value (like "m"), restricts the input range to "n". Quoting
+dependencies is not allowed. Using dependencies with an empty value
+possible is not recommended. See also dep_mbool below.

If the input range is restricted to the single choice "n", dep_bool
silently assigns "n" to /symbol/. If the input range has more than
@@ -469,11 +471,12 @@
=== dep_mbool /prompt/ /symbol/ /dep/ ...

This verb evaluates all of the dependencies in the dependency list.
-Any dependency which has a value of "y" or "m" does not restrict the
-input range. Any dependency which has an empty value is ignored.
-Any dependency which has a value of "n", or which has some other value,
-restricts the input range to "n". Quoting dependencies is not allowed.
-Using dependencies with an empty value possible is not recommended.
+Any dependency which has a value of "y", "m", "!n" or "!" does not
+restrict the input range. Any dependency which has an empty value is
+ignored. Any dependency which has a value of "n", or which has some
+other value, restricts the input range to "n". Quoting dependencies
+is not allowed. Using dependencies with an empty value possible is
+not recommended.

If the input range is restricted to the single choice "n", dep_bool
silently assigns "n" to /symbol/. If the input range has more than
@@ -514,12 +517,13 @@
=== dep_tristate /prompt/ /symbol/ /dep/ ...

This verb evaluates all of the dependencies in the dependency list.
-Any dependency which has a value of "y" does not restrict the input range.
-Any dependency which has a value of "m" restricts the input range to
-"m" or "n". Any dependency which has an empty value is ignored.
-Any dependency which has a value of "n", or which has some other value,
-restricts the input range to "n". Quoting dependencies is not allowed.
-Using dependencies with an empty value possible is not recommended.
+Any dependency which has a value of "y", "!n" or "!" does not restrict
+the input range. Any dependency which has a value of "m" restricts
+the input range to "m" or "n". Any dependency which has an empty
+value is ignored. Any dependency which has a value of "n", or which
+has some other value, restricts the input range to "n". Quoting
+dependencies is not allowed. Using dependencies with an empty value
+possible is not recommended.

If the input range is restricted to the single choice "n", dep_tristate
silently assigns "n" to /symbol/. If the input range has more than

2002-08-09 04:15:15

[permalink] [raw]

Subject: [patch] config language dep_* enhancements

[Kai Germaschewski]
> > As you're hacking Configure anyway, what about "fixing"
> >
> > dep_tristate ' ..' CONFIG_FOO $CONFIG_BAR,

[I wrote]
> I've thought about that many times. I think the cleanest solution is
> to deprecate the '$' entirely:
>
> dep_tristate ' ..' CONFIG_FOO CONFIG_BAR

This applies to 2.4.20pre and (except changelog bits) to 2.5.30 with
offsets. I still haven't touched xconfig, because frankly it scares
me. The tkparse.c vs Peter match is well underway, stay tuned..

diff -urN 2.4.20pre1/Documentation/kbuild/config-language.txt 2.4.20pre1p/Documentation/kbuild/config-language.txt
--- 2.4.20pre1/Documentation/kbuild/config-language.txt 2002-02-25 13:37:51.000000000 -0600
+++ 2.4.20pre1p/Documentation/kbuild/config-language.txt 2002-08-08 23:10:44.000000000 -0500
@@ -84,8 +84,17 @@
to generate dependencies on individual CONFIG_* symbols instead of
making one massive dependency on include/linux/autoconf.h.

- A /dep/ is a dependency. Syntactically, it is a /word/. At run
- time, a /dep/ must evaluate to "y", "m", "n", or "".
+ A /tristate/ is a single character in the set {"y","m","n"}.
+
+ A /dep/ is a dependency. Syntactically, it is a /word/. It is
+ either a /tristate/ or a /symbol/ (with an optional, but
+ deprecated, prefix "$"). At run time, the /symbol/, if present,
+ is expanded to produce a /tristate/. If the /symbol/ has not been
+ defined, the /tristate/ will be "n".
+
+ In addition, the /dep/ may have a prefix "!", which negates the
+ sense of the /tristate/: "!y" and "!m" reduce to "n", and "!n"
+ reduces to "y".

An /expr/ is a bash-like expression using the operators
'=', '!=', '-a', '-o', and '!'.
@@ -439,12 +448,12 @@
=== dep_bool /prompt/ /symbol/ /dep/ ...

This verb evaluates all of the dependencies in the dependency list.
-Any dependency which has a value of "y" does not restrict the input
-range. Any dependency which has an empty value is ignored.
-Any dependency which has a value of "n", or which has some other value,
-(like "m") restricts the input range to "n". Quoting dependencies is not
-allowed. Using dependencies with an empty value possible is not
-recommended. See also dep_mbool below.
+Any dependency which expands to "y" (including "!n" and "!"; see
+above) does not restrict the input range. Any dependency which
+expands to an empty value is ignored. Any dependency which expands to
+"n", or any other value (like "m"), restricts the input range to "n".
+Quoting dependencies is not allowed. Using dependencies with an empty
+value possible is not recommended. See also dep_mbool below.

If the input range is restricted to the single choice "n", dep_bool
silently assigns "n" to /symbol/. If the input range has more than
@@ -469,11 +478,12 @@
=== dep_mbool /prompt/ /symbol/ /dep/ ...

This verb evaluates all of the dependencies in the dependency list.
-Any dependency which has a value of "y" or "m" does not restrict the
-input range. Any dependency which has an empty value is ignored.
-Any dependency which has a value of "n", or which has some other value,
-restricts the input range to "n". Quoting dependencies is not allowed.
-Using dependencies with an empty value possible is not recommended.
+Any dependency which expands to "y" or "m" (including "!n" and "!";
+see above) does not restrict the input range. Any dependency which
+expands to an empty value is ignored. Any dependency which expands to
+"n", or any other value, restricts the input range to "n". Quoting
+dependencies is not allowed. Using dependencies with an empty value
+possible is not recommended.

If the input range is restricted to the single choice "n", dep_bool
silently assigns "n" to /symbol/. If the input range has more than
@@ -514,12 +524,13 @@
=== dep_tristate /prompt/ /symbol/ /dep/ ...

This verb evaluates all of the dependencies in the dependency list.
-Any dependency which has a value of "y" does not restrict the input range.
-Any dependency which has a value of "m" restricts the input range to
-"m" or "n". Any dependency which has an empty value is ignored.
-Any dependency which has a value of "n", or which has some other value,
-restricts the input range to "n". Quoting dependencies is not allowed.
-Using dependencies with an empty value possible is not recommended.
+Any dependency which expands to "y" (including "!n" or "!"; see above)
+does not restrict the input range. Any dependency which expands to
+"m" restricts the input range to "m" or "n". Any dependency which
+expands to an empty value is ignored. Any dependency which expands to
+"n", or any other value, restricts the input range to "n". Quoting
+dependencies is not allowed. Using dependencies with an empty value
+possible is not recommended.

If the input range is restricted to the single choice "n", dep_tristate
silently assigns "n" to /symbol/. If the input range has more than
diff -urN 2.4.20pre1/scripts/Configure 2.4.20pre1p/scripts/Configure
--- 2.4.20pre1/scripts/Configure 2001-07-02 15:56:40.000000000 -0500
+++ 2.4.20pre1p/scripts/Configure 2002-08-08 22:31:49.000000000 -0500
@@ -48,6 +48,15 @@
#
# 24 January 1999, Michael Elizabeth Chastain, <[email protected]>
# - Improve the exit message (Jeff Ronne).
+#
+# 8 Aug 2002, Peter Samuelson <[email protected]>
+# for dependencies in dep_* functions:
+# - deprecate '$' (dep_bool 'foo' CONFIG_FOO CONFIG_BAR CONFIG_BAZ)
+# - allow negation:
+# dep_bool 'New Foo' CONFIG_FOO !CONFIG_OLDFOO
+# dep_bool 'Old Foo' CONFIG_OLDFOO !CONFIG_FOO
+# (Note that since the !CONFIG_OLDFOO is a forward reference, it
+# is meaningless for the line-based interface.)

#
# Make sure we're really running bash.
@@ -232,6 +241,28 @@
}

#
+# dep_calc reduces a dependency line down to a single char [ymn]
+#
+function dep_calc () {
+ local neg arg
+ cur_dep=y # return value
+ for arg; do
+ neg=;
+ case "$arg" in
+ !*) neg=N; arg=${arg#?} ;;
+ esac
+ case "$arg" in
+ y|m|n) ;;
+ *) arg=$(eval echo \$$arg) ;;
+ esac
+ case "$neg$arg" in
+ m) cur_dep=m ;;
+ n|Ny|Nm) cur_dep=n; return ;;
+ esac
+ done
+}
+
+#
# dep_tristate processes a tristate argument that depends upon
# another option or options. If any of the options we depend upon is a
# module, then the only allowable options are M or N. If all are Y, then
@@ -248,18 +279,16 @@
var=$2
need_module=0
shift 2
- while [ $# -gt 0 ]; do
- case "$1" in
- n)
+ dep_calc "$@"
+ case $cur_dep in
+ n)
define_tristate "$var" "n"
return
;;
m)
need_module=1
;;
- esac
- shift
- done
+ esac

if [ $need_module = 1 ]; then
if [ "$CONFIG_MODULES" = "y" ]; then
@@ -299,15 +328,13 @@
ques=$1
var=$2
shift 2
- while [ $# -gt 0 ]; do
- case "$1" in
+ dep_calc "$@"
+ case $cur_dep in
m | n)
define_bool "$var" "n"
return
;;
- esac
- shift
- done
+ esac

bool "$ques" "$var"
}
@@ -316,8 +343,8 @@
ques=$1
var=$2
shift 2
- while [ $# -gt 0 ]; do
- case "$1" in
+ dep_calc "$@"
+ case $cur_dep in
n)
define_bool "$var" "n"
return
diff -urN 2.4.20pre1/scripts/Menuconfig 2.4.20pre1p/scripts/Menuconfig
--- 2.4.20pre1/scripts/Menuconfig 2002-06-14 15:09:40.000000000 -0500
+++ 2.4.20pre1p/scripts/Menuconfig 2002-08-08 22:32:09.000000000 -0500
@@ -77,8 +77,14 @@
# 12 November 2001, Keith Owens <[email protected]>
# Escape double quotes on eval so the quotes are still there on the second
# evaluation, required to handle strings with special characters.
-#
-
+#
+# 8 Aug 2002, Peter Samuelson <[email protected]>
+# for dependencies in dep_* functions:
+# - deprecate '$' (dep_bool 'foo' CONFIG_FOO CONFIG_BAR CONFIG_BAZ)
+# - allow negation:
+# dep_bool 'New Foo' CONFIG_FOO !CONFIG_OLDFOO
+# dep_bool 'Old Foo' CONFIG_OLDFOO !CONFIG_FOO
+# (Yes, forward references DTRT in Menuconfig.)

#
# Change this to TRUE if you prefer all kernel options listed
@@ -202,6 +208,28 @@
}

#
+# Reduces a dependency line down to a single char [ymn]
+#
+function dep_calc () {
+ local neg arg
+ cur_dep=y # return value
+ for arg; do
+ neg=;
+ case "$arg" in
+ !*) neg=N; arg=${arg#?} ;;
+ esac
+ case "$arg" in
+ y|m|n) ;;
+ *) arg=$(eval echo \$$arg) ;;
+ esac
+ case "$neg$arg" in
+ m) cur_dep=m ;;
+ n|Ny|Nm) cur_dep=n; return ;;
+ esac
+ done
+}
+
+#
# Create a tristate radiolist function which is dependent on
# another kernel configuration option.
#
@@ -216,26 +244,13 @@
function dep_tristate () {
ques="$1"
var="$2"
- dep=y
- shift 2
- while [ $# -gt 0 ]; do
- if [ "$1" = y ]; then
- shift
- elif [ "$1" = m ]; then
- dep=m
- shift
- else
- dep=n
- shift $#
- fi
- done
- if [ "$dep" = y ]; then
- tristate "$ques" "$var"
- elif [ "$dep" = m ]; then
- mod_bool "$ques" "$var"
- else
- define_tristate "$var" n
- fi
+ shift 2
+ dep_calc "$@"
+ case $cur_dep in
+ y) tristate "$ques" "$var" ;;
+ m) mod_bool "$ques" "$var" ;;
+ n) define_tristate "$var" n ;;
+ esac
}

#
@@ -245,41 +260,23 @@
function dep_bool () {
ques="$1"
var="$2"
- dep=y
shift 2
- while [ $# -gt 0 ]; do
- if [ "$1" = y ]; then
- shift
- else
- dep=n
- shift $#
- fi
- done
- if [ "$dep" = y ]; then
- bool "$ques" "$var"
- else
- define_bool "$var" n
- fi
+ dep_calc "$@"
+ case $cur_dep in
+ y) bool "$ques" "$var" ;;
+ *) define_bool "$var" n ;;
+ esac
}

function dep_mbool () {
ques="$1"
var="$2"
- dep=y
shift 2
- while [ $# -gt 0 ]; do
- if [ "$1" = y -o "$1" = m ]; then
- shift
- else
- dep=n
- shift $#
- fi
- done
- if [ "$dep" = y ]; then
- bool "$ques" "$var"
- else
- define_bool "$var" n
- fi
+ dep_calc "$@"
+ case $cur_dep in
+ y|m) bool "$ques" "$var" ;;
+ n) define_bool "$var" n ;;
+ esac
}

#
@@ -1088,15 +1085,11 @@
set_x_info "$2" "n"
var="$2"
shift 2
- while [ $# -gt 0 ]; do
- if [ "$1" = y ]; then
- shift
- elif [ "$1" = m -a "$x" != n ]; then
- x=m; shift
- else
- x=n; shift $#
- fi
- done
+ dep_calc "$@"
+ case $cur_dep$x in
+ my) x=m ;;
+ n*) x=n ;;
+ esac
define_tristate "$var" "$x"
}

@@ -1104,13 +1097,8 @@
set_x_info "$2" "n"
var="$2"
shift 2
- while [ $# -gt 0 ]; do
- if [ "$1" = y ]; then
- shift
- else
- x=n; shift $#
- fi
- done
+ dep_calc "$@"
+ [ $cur_dep = y ] || x=n
define_bool "$var" "$x"
}

@@ -1118,13 +1106,8 @@
set_x_info "$2" "n"
var="$2"
shift 2
- while [ $# -gt 0 ]; do
- if [ "$1" = y -o "$1" = m ]; then
- shift
- else
- x=n; shift $#
- fi
- done
+ dep_calc "$@"
+ [ $cur_dep = n ] && x=n
define_bool "$var" "$x"
}

2002-08-09 10:17:52

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

Hi,

On Thu, 8 Aug 2002, Peter Samuelson wrote:

> > Boolean is simple, what about tristate symbols? How does it modify
> > the input range?
>
> !y == n
> !m == n
> !n == y
>
> To me these are the only semantics that make any sense. Certainly if
> it goes in the kernel it needs to be added to config-language.txt.

I would define !m as m, e.g. it would allow

dep_tristate "" CONFIG_OLD !$CONFIG_NEW
dep_tristate "" CONFIG_NEW !$CONFIG_OLD

This means only a single driver could be build into the kernel, but both
could be compiled as module.
If we had real expression there, your semantics could easily be described
as $CONFIG!=n, but it wouldn't be possible to describe my semantics.

bye, Roman

2002-08-09 11:44:02

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

[Peter Samuelson]
> > !y == n
> > !m == n
> > !n == y

[Roman Zippel]
> I would define !m as m, e.g. it would allow
>
> dep_tristate "" CONFIG_OLD !$CONFIG_NEW
> dep_tristate "" CONFIG_NEW !$CONFIG_OLD

You know, that never even occurred to me. Your scheme is not strictly
"logical", but it is much more practical, since it is perfect for
expressing a relatively common (and currently awkward) case.

I'm convinced. Now we have
!y == n
!m == m (significant for dep_tristate and dep_mbool)
!n == n

BTW, does anyone have a problem with my proposal (for 2.5, not
necessarily 2.4) for '/dep_/s/ \$CONFIG/ CONFIG/g' ? That is,

-dep_tristate "" CONFIG_FOO_X CONFIG_FOO CONFIG_BAR !CONFIG_BAZ
+dep_tristate "" CONFIG_FOO_X $CONFIG_FOO $CONFIG_BAR !$CONFIG_BAZ

Advantages:

- the config files are more readable, especially when using "!"

- can support the old syntax with no extra code

and most importantly

- resolves the parsing difficulty with detecting an undefined value
in dep_* statements. Currently the undefined value is documented as
"ignored, but try to avoid the situation".

which leads to

- allows us to drop all those 'define_bool CONFIG_FOO n' statements
whose main purpose was to avoid the empty value

Eh? I posted a patch earlier; it was trivial, despite having a syntax
error in Configure (deleted a 'while...do', forgot the 'done') which
only proves that I don't test stuff very rigorously. Menuconfig
actually shrunk, due to factoring. If and when I get my head around
xconfig, we'll see how ugly this stuff does or doesn't get, but then
again, if xconfig were made uglier, would anyone notice?

Peter

2002-08-09 12:03:56

by Russell King

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

On Fri, Aug 09, 2002 at 06:47:41AM -0500, Peter Samuelson wrote:
> I'm convinced. Now we have
> !y == n
> !m == m (significant for dep_tristate and dep_mbool)
> !n == n

Erm, !n == n ???

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

2002-08-09 12:45:45

[permalink] [raw]

Subject: Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

[Russell King]
> Erm, !n == n ???

Duh. I need some serious sleep. That wasn't the only semantically
significant typo in my post, only the worst. Obviously, !n == y.

Peter

2002-08-10 15:37:53

by Gerald Britton

[permalink] [raw]

Subject: local apic on up broken with 2.4.20-pre1-ac1

I believe this has been broken for the last few -ac kernels.

gcc -D__KERNEL__ -I/devel/rpm/BUILD/kernel-2.4.20pre1ac1/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -I /usr/lib/gcc-lib/i386-redhat-linux/2.96/include -DKBUILD_BASENAME=mpparse -c -o mpparse.o mpparse.c
mpparse.c:74: `dest_LowestPrio' undeclared here (not in a function)
mpparse.c: In function `smp_read_mpc':
mpparse.c:609: `dest_Fixed' undeclared (first use in this function)
mpparse.c:609: (Each undeclared identifier is reported only once
mpparse.c:609: for each function it appears in.)
mpparse.c:609: `dest_LowestPrio' undeclared (first use in this function)
make[2]: *** [mpparse.o] Error 1
make[2]: Leaving directory `/devel/rpm/BUILD/kernel-2.4.20pre1ac1/arch/i386/kernel'

-- Gerald

2002-08-11 21:08:48

by Matt Domsch

[permalink] [raw]

Subject: RE: Linux 2.4.20-pre1

> > > > <[email protected]> (02/08/05 1.629)
> > > > [PATCH] PATCH: Add EFI partition support
> > >
> > > Needs this to compile....
> > >
> > > --- linux/include/asm-ia64/efi.h.orig Sun Aug 11 01:41:10 2002
> > > +++ linux/include/asm-ia64/efi.h Sun Aug 11 01:43:38 2002
> > > @@ -166,6 +166,9 @@
> > > * EFI Configuration Table and GUID definitions
> > > */e
56> > >
> > > +#define NULL_GUID \
> > > + ((efi_guid_t) { 0x00000000, 0x0000, 0x0000, { 0x00,
> 0x00, 0x0, 0x00, 0x00, 0x00, 0x00, 0x00 }})
> > > +
> >
> > Not a good plan. EFI can be used on non ia64 so NULL_GUID belongs
> > somewhere else

Two things:
1) there is an accompanying patch to the EFI patch which adds NULL_GUID and
changes the definition of GUIDs to use the helper macro EFI_GUID to solve
endianness issues. David Mosberger has blessed my submission of this, and
it's been in the ia64 port patch for many months. Patch or cset:

http://domsch.com/linux/patches/gpt/linux-2.4.19-rc1-efiguidt.patch
http://domsch.com/linux/patches/gpt/linux-2.4-gpt-efiguidt.cset

2) Yes, it's ugly that fs/partitions/efi.c includes asm-ia64/efi.h to pick
up the definitions. David told me 12-18 months ago that Linus didn't want
an include/linux/efi.h because only IA64 today uses it, even though nothing
in it is IA-64 specific - it *could* be made generic. So, I had three
choices:
a) include asm-ia64/efi.h and comment (taken)
b) Move asm-ia64/efi.h to linux/efi.h (believed rejected)
c) Duplicate typedefs.

I'd be happy to submit a patch moving asm-ia64/efi.h into include/linux/ if
it would be accepted.

Thanks,
Matt

--
Matt Domsch
Sr. Software Engineer, Lead Engineer, Architect
Dell Linux Solutions http://www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
#1 US Linux Server provider for 2001 and Q1/2002! (IDC May 2002)

2002-08-12 11:00:11

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

Peter Samuelson wrote:
>
> > You're willing to potentially perturb 2.4?
>
> This stuff is trivial enough, and easy enough to test, that I think it
> could go in 2.4, yes.

I think you're underestimating the Gordian knot that is the CML1 corpus.

> Obviously xconfig would need to be dealt with
> in sync with the others, which I'm not doing during the prototyping /
> idea-mongering stage.

Fair enough.

> > I'm pleased to see that you have preserved those semantics. There
> > are many places in the corpus where a dep_* lists as a dependency a
> > variable which is not defined until later, or is only defined in
> > some architectures, or is never defined. Earlier today I tweaked up
> > gcml2 to detect them and found 260 in 2.5.29.
>
> You give me too much credit. The main motivation for dropping the '$'
> was to make possible the "" == "n" semantics. That the patch failed
> to do so was accident, not design.

Ah, well that's more disturbing. Changing the existing semantics, regardless
of how broken we all agree they are, is asking for a world of trouble. To
pick an example, in 2.5.29 drivers/ide/Config.in:17 is

dep_tristate ' SCSI emulation support' CONFIG_BLK_DEV_IDESCSI $CONFIG_ATAPI $CONFIG_BLK_DEV_IDE $CONFIG_SCSI

But at this point in the menu tree for 14 of 17 architectures, CONFIG_SCSI has
not yet been defined. The result is that CONFIG_BLK_DEV_IDESCSI only works
in "make config" and "make allyesconfig" precisely because of the semantic that
you wish to change.

In fact this is the first one gcml2 finds, I don't particularly feel like
trawling through the other two hundred-odd. Some of them are harmless, I don't
know how many.

> I know the current behavior is documented, but I had thought this was
> because changing the behavior was not feasible due to our Bash-based
> "JIT parsers".

Yes, changing the behaviour is infeasible with shell-based parsers. However,
there is now a body of rules which implictly depend on the semantics.

> Can you provide a rationale for why the current
> behavior is desirable?

I wouldn't call it "desirable". I would use words like "clunky", "congealed",
"unorthogonal", "riddled with errors", and "very hard to fix" like the rest of
the config language.

> It seems to me that it only encourages buggy
> Config.in code (since "" == "n" in other contexts like the #defines),

And "" != "n" in other contexts, like if [];then statements. Did I mention
"unorthogonal" ?

The problem is that logic in config language is implicitly four-state, with
the null or empty value being a separate value distinct from y, m and n.
The fact that both "" and "n" mean "don't build this object" to kbuild doesn't
mean that "" and "n" are the same thing. This isn't really obvious.

One example where there is a semantic difference between "" and "n" would be
an autoconfigurator, where "n" would mean "I have probed for this hardware and
it is not present" but "" means something like "I have not probed".

> and I don't see any benefits other than that it's the status quo.

I'm not defending the current syntax. It sucks and it's broken. But
fixing it will break things that currently aren't broken (or more accurately
are broken twice in opposite directions). If it's your intention to change
the semantics of "", perhaps it would be better to add new statements which
feature the new syntax and new semantics *only* and have no backwards
compatibility baggage. An example of this approach is the "nchoice" statement,
which does the same thing as "choice" but with a more civilized syntax.

> > > + case "$arg" in
> > > + y|m|n) ;;
> > > + *) arg=$(eval echo \$$arg) ;;
> >
> > Don't you want to check at this point that arg starts with CONFIG_?
> > Also, how about quoting \$$arg ?
>
> I suppose one could add sanity checks / diagnostics, but there are no
> other valid cases, so that's all they would be.

Yes, but there are invalid cases, and surely you don't want to help to
*increase* the amount of bugginess in the rules corpus?

Greg.
--
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.

2002-08-12 14:43:11

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

On Mon, 12 Aug 2002, Greg Banks wrote:

> > > I'm pleased to see that you have preserved those semantics. There
> > > are many places in the corpus where a dep_* lists as a dependency a
> > > variable which is not defined until later, or is only defined in
> > > some architectures, or is never defined. Earlier today I tweaked up
> > > gcml2 to detect them and found 260 in 2.5.29.
> >
> > You give me too much credit. The main motivation for dropping the '$'
> > was to make possible the "" == "n" semantics. That the patch failed
> > to do so was accident, not design.
>
> Ah, well that's more disturbing. Changing the existing semantics, regardless
> of how broken we all agree they are, is asking for a world of trouble. To
> pick an example, in 2.5.29 drivers/ide/Config.in:17 is
>
> dep_tristate ' SCSI emulation support' CONFIG_BLK_DEV_IDESCSI $CONFIG_ATAPI $CONFIG_BLK_DEV_IDE $CONFIG_SCSI
>
> But at this point in the menu tree for 14 of 17 architectures, CONFIG_SCSI has
> not yet been defined. The result is that CONFIG_BLK_DEV_IDESCSI only works
> in "make config" and "make allyesconfig" precisely because of the semantic that
> you wish to change.

But so the change would be a good thing, right? It would make the behavior
consistent between all configuration tools, CONFIG_BLK_DEV_IDESCSI would
be not selectable in either. So people would have to notice that this
statement is broken and fix it.

> > I know the current behavior is documented, but I had thought this was
> > because changing the behavior was not feasible due to our Bash-based
> > "JIT parsers".
>
> Yes, changing the behaviour is infeasible with shell-based parsers. However,
> there is now a body of rules which implictly depend on the semantics.

If they do, they should be fixed. And, as I pointed out before, it is
possible to fix even shell-based parsers.

> > Can you provide a rationale for why the current
> > behavior is desirable?
>
> I wouldn't call it "desirable". I would use words like "clunky", "congealed",
> "unorthogonal", "riddled with errors", and "very hard to fix" like the rest of
> the config language.

So you agree a bit of spring cleaning wouldn't hurt, right? ;)

> > It seems to me that it only encourages buggy
> > Config.in code (since "" == "n" in other contexts like the #defines),
>
> And "" != "n" in other contexts, like if [];then statements. Did I mention
> "unorthogonal" ?

Well, you're right here. Which makes me think of my original idea as to
define all CONFIG_* values to "n" unless they've explicitly been assign
another value before.

> The problem is that logic in config language is implicitly four-state, with
> the null or empty value being a separate value distinct from y, m and n.
> The fact that both "" and "n" mean "don't build this object" to kbuild doesn't
> mean that "" and "n" are the same thing. This isn't really obvious.
>
> One example where there is a semantic difference between "" and "n" would be
> an autoconfigurator, where "n" would mean "I have probed for this hardware and
> it is not present" but "" means something like "I have not probed".

The main usage currently is "make oldconfig", though .config may be a bit
confusing: Questions which have been answered before (even with "n") will
not be asked again, whereas for undefined symbols, the corresponding
question is put.

So I think the logic should really be tristate, "n","m","y", plus
additionally a list of CONFIG_* values which have been defined (as opposed
to just being "n" by default). This would get rid of the non-intuitive
behavior of dep_* and allow simplifying all the if [ == "n" || == "" ]
duplication. It's a bit cumbersome to implement in shell, but surely
possible.

Of course, this is a 2.5 change, though the only potential for breakage
are the dep_* statements which are arguably already broken. It shouldn't
be too hard to come up with a script which points out the dep_* statements
which reference symbols defined only later (or use gcml2, which I
understand can do that already?) to see how much breakage there may be.

--Kai

2002-08-12 15:46:53

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

[I wrote]
> > This stuff is trivial enough, and easy enough to test, that I
> > think it could go in 2.4, yes.

[Greg Banks]
> I think you're underestimating the Gordian knot that is the CML1 corpus.

Yes, very possibly.

> To pick an example, in 2.5.29 drivers/ide/Config.in:17 is
>
> dep_tristate ' SCSI emulation support' CONFIG_BLK_DEV_IDESCSI $CONFIG_ATAPI $CONFIG_BLK_DEV_IDE $CONFIG_SCSI
>
> But at this point in the menu tree for 14 of 17 architectures, CONFIG_SCSI has
> not yet been defined. The result is that CONFIG_BLK_DEV_IDESCSI only works
> in "make config" and "make allyesconfig" precisely because of the semantic that
> you wish to change.

Thank you! That's what I wanted to know. I had no idea there existed
this class of bug (yes it's a bug). I don't know why I should be
surprised, since the 17 architectures all have separately-maintained
config.in files, most of which were written by porting gurus, not
'make config' gurus.

That one example is more than enough to convince me *not* to try
changing the "ignore empty deps" rule for 2.4. 2.5 is a different
matter, though..

> In fact this is the first one gcml2 finds, I don't particularly feel
> like trawling through the other two hundred-odd. Some of them are
> harmless, I don't know how many.

This is like the Stanford checker stuff. These are bugs. You have
the means to find them automatically, but not the time or desire to
fix them. Post a list and perhaps others will pitch in. Something
like

drivers/ide/Config.in:17: In dep_tristate CONFIG_BLK_DEV_IDESCSI:
drivers/ide/Config.in:17: CONFIG_SCSI not defined for i386, ppc, ...

In this case the fix would be to move CONFIG_BLK_DEV_IDESCSI to the
SCSI subsystem, where in my opinion it belonged anyway.

This would break down if there are any actual cycles - things which
can't logically be moved to a place after the definitions of the
facilities on which they depend.

That we have to worry about this at all is an artifact of using a
procedural langauge, rather than a declarative language like Prolog or
CML2. I *really* don't want to go *there*, though. (:

> And "" != "n" in other contexts, like if [];then statements.

That is true. But that should not affect the dep_* logic, should it?
The point here is that people who aren't hip-deep in config language
code don't think about them being separate. Ergo bugs.

> If it's your intention to change the semantics of "", perhaps it
> would be better to add new statements which feature the new syntax
> and new semantics *only* and have no backwards compatibility
> baggage. An example of this approach is the "nchoice" statement,
> which does the same thing as "choice" but with a more civilized
> syntax.

I've been thinking hard about a new sort of 'if' statement that
doesn't look like a test command. (Yes, it's my mission to eventually
get rid of the '$'s in config language. I think it can be done,
piecemeal, over a long period of time. This is if we don't end up
adopting a whole new language like CML2 or Roman's stuff.)

Peter

2002-08-12 19:42:49

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

Hi,

On Mon, 12 Aug 2002, Kai Germaschewski wrote:

> Of course, this is a 2.5 change, though the only potential for breakage
> are the dep_* statements which are arguably already broken. It shouldn't
> be too hard to come up with a script which points out the dep_* statements
> which reference symbols defined only later (or use gcml2, which I
> understand can do that already?) to see how much breakage there may be.

Most should be fixable. The biggest problem are recursive references like
this:

if [ OLD != y ]; then
tristate NEW
fi
if [ NEW != y ]; then
tristate OLD
fi

with the latest modifications this can be written as:

dep_tristate NEW !OLD
dep_tristate OLD !NEW

This still has the back reference and you have to run 'make config'
twice to change NEW from n to y.
It's possible to fix this:

tristate DRV
if [ DRV == y ]; then
choice OLD NEW
fi
if [ DRV == m ]; then
dep_tristate NEW DRV
dep_tristate OLD DRV
fi

That should look interesting in xconfig, but we could define a new
statement for this, but you get a new problem if the drivers had their own
suboptions and you want to arrange them most user friendly directly after
the driver statement like this:

tristate DRV
if [ DRV == y ]; then
choice OLD NEW
if [ NEW == y ]; then
bool ...
fi
if [ OLD == y ]; then
bool ...
fi
fi
if [ DRV == m ]; then
dep_tristate NEW DRV
if [ NEW == y ]; then
bool ...
fi
dep_tristate OLD DRV
if [ OLD == y ]; then
bool ...
fi
fi

This should work quite well with config and menuconfig and maybe someone
fixes xconfig, so a lot can be fixed within cml1, but it won't be
necessarily nice. :) I didn't make up this example, just look at
CONFIG_SCSI_AIC7XXX* which would need fixing like this.
More examples of the cml1 limitations can be found in arch/ppc/config.in -
a single choice statement needs to be splitted into multiple choice
statements.
The current config is really very limited and can not be easily extended
(just try adding the help text or build information). At some point we
have to drop cml1 and replace it with something else. This doesn't has be
very painful, I have a tool that can convert most of the current config
into whatever you want.

bye, Roman

2002-08-12 21:37:15

[permalink] [raw]

Subject: Re: [kbuild-devel] Re: [patch] config language dep_* enhancements

On Mon, Aug 12, 2002 at 09:45:37PM +0200, Roman Zippel wrote:

> More examples of the cml1 limitations can be found in arch/ppc/config.in -
> a single choice statement needs to be splitted into multiple choice
> statements.

Er, which are you referring to here? All of the choice statements are
done for clarity here. :) Tho I was (and have been) pondering creating
arch/ppc/platforms/Config-[468]xx.in, which would rather nicely move all
of the options related to IBM 4xx processors to one file, Motorola 8xx
to another, and general PPC's nicely.

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

2002-08-12 22:10:52

[permalink] [raw]

Subject: Re: [kbuild-devel] Re: [patch] config language dep_* enhancements

Hi,

On Mon, 12 Aug 2002, Tom Rini wrote:

> > More examples of the cml1 limitations can be found in arch/ppc/config.in -
> > a single choice statement needs to be splitted into multiple choice
> > statements.
>
> Er, which are you referring to here? All of the choice statements are
> done for clarity here. :) Tho I was (and have been) pondering creating
> arch/ppc/platforms/Config-[468]xx.in, which would rather nicely move all
> of the options related to IBM 4xx processors to one file, Motorola 8xx
> to another, and general PPC's nicely.

There is still a bit of overlap. Roughly it's possible to sort the machine
types by cpu type, but IMO it's not the best solution. I think it would be
better to sort them by general machine type.

bye, Roman

2002-08-12 22:15:34

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

On Tue, Aug 13, 2002 at 12:13:51AM +0200, Roman Zippel wrote:
> Hi,
>
> On Mon, 12 Aug 2002, Tom Rini wrote:
>
> > > More examples of the cml1 limitations can be found in arch/ppc/config.in -
> > > a single choice statement needs to be splitted into multiple choice
> > > statements.
> >
> > Er, which are you referring to here? All of the choice statements are
> > done for clarity here. :) Tho I was (and have been) pondering creating
> > arch/ppc/platforms/Config-[468]xx.in, which would rather nicely move all
> > of the options related to IBM 4xx processors to one file, Motorola 8xx
> > to another, and general PPC's nicely.
>
> There is still a bit of overlap. Roughly it's possible to sort the machine
> types by cpu type, but IMO it's not the best solution. I think it would be
> better to sort them by general machine type.

Er, 'general machine type' ?

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

2002-08-12 22:29:54

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

Hi,

On Mon, 12 Aug 2002, Tom Rini wrote:

> > There is still a bit of overlap. Roughly it's possible to sort the machine
> > types by cpu type, but IMO it's not the best solution. I think it would be
> > better to sort them by general machine type.
>
> Er, 'general machine type' ?

+-RPX
| +- ...
+-TQM
| +- ...
+-Motorola
| +- ...
...

A bit more flexibility certainly wouldn't hurt. :)

bye, Roman

2002-08-12 22:43:37

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

On Tue, Aug 13, 2002 at 12:32:50AM +0200, Roman Zippel wrote:
> Hi,
>
> On Mon, 12 Aug 2002, Tom Rini wrote:
>
> > > There is still a bit of overlap. Roughly it's possible to sort the machine
> > > types by cpu type, but IMO it's not the best solution. I think it would be
> > > better to sort them by general machine type.
> >
> > Er, 'general machine type' ?
>
> +-RPX
> | +- ...
> +-TQM
> | +- ...
> +-Motorola
> | +- ...
> ...
>
> A bit more flexibility certainly wouldn't hurt. :)

What does that gain however? And it wouldn't make as much sense to
offer the IBM Spruce (750) next to the IBM Walnut (405GP).

So in short, the various choice menus in arch/ppc/config.in aren't to
work around CML1 issues, it an intentional design (which really needs to
become 4 files).

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

2002-08-12 23:14:22

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

Hi,

On Mon, 12 Aug 2002, Tom Rini wrote:

> > A bit more flexibility certainly wouldn't hurt. :)
>
> What does that gain however? And it wouldn't make as much sense to
> offer the IBM Spruce (750) next to the IBM Walnut (405GP).

You weren't forced to sort them by cpu type. Maybe it works as is, you
should know that better than me.
I only used it as an example, because my tool has problems to
automatically convert this construct into something useful (e.g. because
of CONFIG_WILLOW in 2 seperate choice statements).

bye, Roman

2002-08-12 23:29:11

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

On Tue, Aug 13, 2002 at 01:17:15AM +0200, Roman Zippel wrote:
> Hi,
>
> On Mon, 12 Aug 2002, Tom Rini wrote:
>
> > > A bit more flexibility certainly wouldn't hurt. :)
> >
> > What does that gain however? And it wouldn't make as much sense to
> > offer the IBM Spruce (750) next to the IBM Walnut (405GP).
>
> You weren't forced to sort them by cpu type. Maybe it works as is, you
> should know that better than me.

heh. It is something actually works pretty well, and with the rare
exception of things which can show up twice (see below) it's rather
logical too.

> I only used it as an example, because my tool has problems to
> automatically convert this construct into something useful (e.g. because
> of CONFIG_WILLOW in 2 seperate choice statements).

That's because CONFIG_WILLOW can either have an 8260 CPU or a 7xx/74xx
CPU. Or I think an ARM cpu... And unfortunatly I don't think support
for anything beyond maybe 8260 is actually in the trees right now
anyhow.

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

2002-08-13 00:02:49

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

[Roman Zippel]
> with the latest modifications this can be written as:
>
> dep_tristate NEW !OLD
> dep_tristate OLD !NEW
>
> This still has the back reference and you have to run 'make config'
> twice to change NEW from n to y.

I don't see this as a big problem. Most people don't use the bare
Configure script anyway, except for 'make oldconfig'.

With the ! patch, Menuconfig does the right thing here.

> It's possible to fix this:
>
> tristate DRV
> if [ DRV == y ]; then
> choice OLD NEW
> fi
> if [ DRV == m ]; then
> dep_tristate NEW DRV
> dep_tristate OLD DRV
> fi

Simpler and perhaps more intuitive:

tristate DRV
dep_mbool DRV_OLD DRV

dep_mbool COMMON_OPT DRV
dep_mbool OLD_OPT1 DRV_OLD
dep_mbool OLD_OPT2 DRV_OLD
dep_mbool NEW_OPT1 DRV !DRV_OLD
dep_mbool NEW_OPT2 DRV !DRV_OLD

I don't see a real need for a separate symbol announcing DRV_NEW. Let
the Makefile cope.

Peter

2002-08-13 03:28:34

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

Roman Zippel wrote:
>
> Most should be fixable. The biggest problem are recursive references like
> this:
>
> if [ OLD != y ]; then
> tristate NEW
> fi
> if [ NEW != y ]; then
> tristate OLD
> fi
>
> [...]It's possible to fix this:
>
> tristate DRV
> if [ DRV == y ]; then
> choice OLD NEW
> fi
> if [ DRV == m ]; then
> dep_tristate NEW DRV
> dep_tristate OLD DRV
> fi
>
> That should look interesting in xconfig,

It will also give gcml2 conniptions trying to figure out a set of constraints
which will enforce the intended behaviour. Please please don't.

If there are any loops (and I don't know of any) then the logic is broken and
needs to be fixed, not enforced through clever tricks.

> This should work quite well with config and menuconfig and maybe someone
> fixes xconfig, so a lot can be fixed within cml1, but it won't be
> necessarily nice. :) I didn't make up this example, just look at
> CONFIG_SCSI_AIC7XXX* which would need fixing like this.

I will look, but I seem to remember that this code was just broken when
Keith Owens was trying to make it work in kbuild 2.5.

> The current config is really very limited and can not be easily extended
> (just try adding the help text or build information). At some point we
> have to drop cml1 and replace it with something else.

<sigh>once more into the breach...

> This doesn't has be
> very painful, I have a tool that can convert most of the current config
> into whatever you want.

The problem is deciding what the original rules were supposed to mean, and
then reproducing that behaviour exactly in the new language. The alternative
is fixing the problems as we convert, but then we end up with CML2 and the
"there's no way to verify the rulebase is the same" argument.

Greg.
--
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.

2002-08-13 03:36:12

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

[Greg Banks]
> Ah. If you're willing to knowingly feed Linus with patches that
> break current config behaviour, then OK we have a way to proceed.

Things knowingly break in 2.5 all the time. I for one have no problem
with this. Especially since the breakage is so easy to pinpoint,
thanks to your script.

> I don't think there's any value to gratuitously breaking 2.4's
> config. That's the point of a "stable" series right?

Correct. I for one have no intention of changing 2.4 semantics,
except to expand them to allow '!' syntax, if I can finish that up.

> Ah, glad you asked, see attached output from the latest version of gcml2
> (not yet released).

Thank you thank you thank you! Exactly what I wanted!

Now, while some (perhaps a lot) of these instances will break with the
proposed new semantics, many will not. Starting from the top:

> =====alpha
> warning:drivers/pcmcia/Config.in:22:forward declared symbol "CONFIG_ARCH_SA1100" used in dependency list for "CONFIG_PCMCIA_SA1100"

In context:

if [ "$CONFIG_ARM" = "y" ]; then
dep_tristate ' SA1100 support' CONFIG_PCMCIA_SA1100 $CONFIG_ARCH_SA1100 $CONFIG_PCMCIA
fi

With the new semantics, there would be no need for the 'if' statement.
CONFIG_ARCH_SA1100 is a sufficient guard, since non-ARM machines will
never define it.

The next 7 lines are similar, with CONFIG_PPC, CONFIG_MIPS and
CONFIG_ARM as the guards.

> warning:drivers/block/Config.in:38:forward declared symbol "CONFIG_SCSI" used in dependency list for "CONFIG_CISS_SCSI_TAPE"

This one is legit. It's a weird case where a single driver can be
built with or without using the SCSI subsystem - in effect, two
drivers sharing a single piece of hardware and presenting two views of
it.

My preferred "fix" is to move the 'tristate CONFIG_SCSI' to early in
the Block Devices menu. ATA should be under Block Devices too, come
to think of it, and perhaps a generic guard for non-IDE-non-SCSI RAID
cards. The actual menus could come later under toplevel, or be nested
within "Block Devices".

> warning:drivers/ide/Config.in:21:forward declared symbol "CONFIG_SCSI" used in dependency list for "CONFIG_BLK_DEV_IDESCSI"

See above.

> warning:drivers/ide/Config.in:84:forward declared symbol "CONFIG_ARCH_ACORN" used in dependency list for "CONFIG_BLK_DEV_IDE_ICSIDE"
> warning:drivers/ide/Config.in:88:forward declared symbol "CONFIG_ARCH_ACORN" used in dependency list for "CONFIG_BLK_DEV_IDE_RAPIDE"
> warning:drivers/ide/Config.in:91:forward declared symbol "CONFIG_AMIGA" used in dependency list for "CONFIG_BLK_DEV_GAYLE"
> warning:drivers/ide/Config.in:95:forward declared symbol "CONFIG_ZORRO" used in dependency list for "CONFIG_BLK_DEV_BUDDHA"
> warning:drivers/ide/Config.in:98:forward declared symbol "CONFIG_ATARI" used in dependency list for "CONFIG_BLK_DEV_FALCON_IDE"
> warning:drivers/ide/Config.in:101:forward declared symbol "CONFIG_MAC" used in dependency list for "CONFIG_BLK_DEV_MAC_IDE"
> warning:drivers/ide/Config.in:104:forward declared symbol "CONFIG_Q40" used in dependency list for "CONFIG_BLK_DEV_Q40IDE"
> warning:drivers/ide/Config.in:107:forward declared symbol "CONFIG_8xx" used in dependency list for "CONFIG_BLK_DEV_MPC8xx_IDE"
> warning:drivers/net/Config.in:28:forward declared symbol "CONFIG_ARCH_EBSA110" used in dependency list for "CONFIG_ARM_AM79C961A"
> warning:drivers/net/Config.in:34:forward declared symbol "CONFIG_ALL_PPC" used in dependency list for "CONFIG_MACE"
> warning:drivers/net/Config.in:38:forward declared symbol "CONFIG_ALL_PPC" used in dependency list for "CONFIG_BMAC"
> warning:drivers/net/Config.in:48:forward declared symbol "CONFIG_GSC_LASI" used in dependency list for "CONFIG_LASI_82596"
> warning:drivers/net/Config.in:239:forward declared symbol "CONFIG_PPC_ISERIES" used in dependency list for "CONFIG_VETH"

All obviously tied to a specific arch. Most but not all are guarded
by ARCH_* symbols, but that doesn't matter - with the new semantics
they work with or without extra guards.

All in all, by asserting that 'n' == '', you can drop all the
'define_bool FOO n' from the arch/*/config.in files (like CONFIG_SBUS
on i386 or CONFIG_PCI on s390), and you can drop a *lot* of guard 'if'
statements. A few things would actually break, like not defining
CONFIG_SCSI soon enough.

I think it's worth it. It will take some time to go through your 260
unique warnings (984 total), of course.

BTW - speaking of the length of your warnings list - what would be
*really* nice would be a way to determine that a particular "forward
declared symbol" is actually a "never-in-this-arch declared symbol".
That would eliminate most of the false positives. If for example we
can determine that we will never define CONFIG_ZORRO on this arch, we
can safely assume that anything which depends on CONFIG_ZORRO *should*
be suppressed. (Modulo outright bugs where someone wrote
$CONFIG_ZORRO for something that does not in fact require zorro.)

Peter

2002-08-13 03:31:25

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

Roman Zippel wrote:
>
> I only used it as an example, because my tool has problems to
> automatically convert this construct into something useful (e.g. because
> of CONFIG_WILLOW in 2 seperate choice statements).

You too? I had to rewrite my branch merging code to make CONFIG_WILLOW fit.

Greg.
--
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.

2002-08-13 04:26:40

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

Peter Samuelson wrote:
>
> [Greg Banks]
> > Ah, glad you asked, see attached output from the latest version of gcml2
> > (not yet released).
>
> Thank you thank you thank you! Exactly what I wanted!

Pleased to be of service ;-)

> Now, while some (perhaps a lot) of these instances will break with the
> proposed new semantics, many will not. Starting from the top:
>
> > =====alpha
> > warning:drivers/pcmcia/Config.in:22:forward declared symbol "CONFIG_ARCH_SA1100" used in dependency list for "CONFIG_PCMCIA_SA1100"
>
> In context:
>
> if [ "$CONFIG_ARM" = "y" ]; then
> dep_tristate ' SA1100 support' CONFIG_PCMCIA_SA1100 $CONFIG_ARCH_SA1100 $CONFIG_PCMCIA
> fi
>
> With the new semantics, there would be no need for the 'if' statement.
> CONFIG_ARCH_SA1100 is a sufficient guard, since non-ARM machines will
> never define it.

Agreed, the current form is a direct result of the current dep_tristate
semantics and would not be necessary with your proposed semantics.

> > warning:drivers/block/Config.in:38:forward declared symbol "CONFIG_SCSI" used in dependency list for "CONFIG_CISS_SCSI_TAPE"
>
> This one is legit. It's a weird case where a single driver can be
> built with or without using the SCSI subsystem - in effect, two
> drivers sharing a single piece of hardware and presenting two views of
> it.

Bizarre.

> My preferred "fix" is to move the 'tristate CONFIG_SCSI' to early in
> the Block Devices menu. ATA should be under Block Devices too, come
> to think of it, and perhaps a generic guard for non-IDE-non-SCSI RAID
> cards. The actual menus could come later under toplevel, or be nested
> within "Block Devices".

Along these lines, CML2 had a menu 'buses' very early in the root of
the tree, containing queries for ISA, PCI, MCA, SERIAL, PARPORT,
HOTPLUG, IDE, SCSI, USB, IEEE1394 and FC4. I won't post the code
here because I can't fully understand it anymore :-(

> All in all, by asserting that 'n' == '', you can drop all the
> 'define_bool FOO n' from the arch/*/config.in files (like CONFIG_SBUS
> on i386 or CONFIG_PCI on s390), and you can drop a *lot* of guard 'if'
> statements. A few things would actually break, like not defining
> CONFIG_SCSI soon enough.

You will also probably want to deal with the cases where possibly null-valued
symbols are compared against "n" like this

if [ "$CONFIG_NOT_DECLARED" != "n" ]; then....

73 forward-compared-to-n
13 drivers/parport/Config.in:40:CONFIG_ZORRO
13 sound/oss/Config.in:209:CONFIG_INPUT_GAMEPORT
11 drivers/parport/Config.in:14:CONFIG_SERIAL
10 drivers/media/video/Config.in:33:CONFIG_USB
6 drivers/video/Config.in:134:CONFIG_I2C
3 drivers/net/Config.in:324:CONFIG_CARDBUS
3 drivers/scsi/Config.in:264:CONFIG_PCMCIA
2 drivers/char/Config.in:193:CONFIG_PCMCIA
2 drivers/net/Config.in:327:CONFIG_PCMCIA
2 drivers/net/wireless/Config.in:27:CONFIG_PCMCIA
2 drivers/net/wireless/Config.in:41:CONFIG_PCMCIA
2 drivers/scsi/Config.in:116:CONFIG_PARPORT
1 arch/alpha/config.in:262:CONFIG_PROC_FS
1 arch/sh/config.in:298:CONFIG_MAPLE
1 drivers/ide/Config.in:26:CONFIG_PCI
1 drivers/parport/Config.in:27:CONFIG_PCMCIA

> I think it's worth it. It will take some time to go through your 260
> unique warnings (984 total), of course.

;-)

> BTW - speaking of the length of your warnings list - what would be
> *really* nice would be a way to determine that a particular "forward
> declared symbol" is actually a "never-in-this-arch declared symbol".
> That would eliminate most of the false positives. If for example we
> can determine that we will never define CONFIG_ZORRO on this arch, we
> can safely assume that anything which depends on CONFIG_ZORRO *should*
> be suppressed.

Shouldn't be too hard, I'm already doing something like this to distinguish
between forward declared and undeclared symbols for the forward-reference
and undeclared-symbol warnings.

Greg.
--
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.

2002-08-13 07:51:48

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

Hi,

On Mon, 12 Aug 2002, Peter Samuelson wrote:

> tristate DRV
> dep_mbool DRV_OLD DRV
>
> dep_mbool COMMON_OPT DRV
> dep_mbool OLD_OPT1 DRV_OLD
> dep_mbool OLD_OPT2 DRV_OLD
> dep_mbool NEW_OPT1 DRV !DRV_OLD
> dep_mbool NEW_OPT2 DRV !DRV_OLD

This way you can't compile old and new driver as module.

bye, Roman

2002-08-13 09:29:55

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

Hi,

On Tue, 13 Aug 2002, Greg Banks wrote:

> > This doesn't has be
> > very painful, I have a tool that can convert most of the current config
> > into whatever you want.
>
> The problem is deciding what the original rules were supposed to mean, and
> then reproducing that behaviour exactly in the new language. The alternative
> is fixing the problems as we convert, but then we end up with CML2 and the
> "there's no way to verify the rulebase is the same" argument.

My only requirement is that the resulting rulebase is usable and roughly
the same, some small bugs are IMO acceptable.
CML2 has more problems than this. It's a very flexible but also very
complex language, which makes it hard to use. It was also not very wise to
create a complete new and different rulebase, which made it very hard to
compare both.

bye, Roman

2002-08-13 18:39:47

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

On Tue, 13 Aug 2002, Greg Banks wrote:

> Kai Germaschewski wrote:
> >
> > But so the change would be a good thing, right? It would make the behavior
> > consistent between all configuration tools,
>
> Sorry, I don't understand what you're getting at. Currently the behaviour is
> consistent between config, menuconfig and xconfig: null-valued deps are ignored.

For some reason, I thought that menuconfig or xconfig were handling the ""
case differently. Apparently not, sorry about that.

> > CONFIG_BLK_DEV_IDESCSI would
> > be not selectable in either. So people would have to notice that this
> > statement is broken and fix it.
>
> Ah. If you're willing to knowingly feed Linus with patches that break current
> config behaviour, then OK we have a way to proceed.

Well, it'd be nice to first "fix" the dep_* statements so that they don't
break when that change is done (i.e. in this case, moving IDESCSI behind
CONFIG_SCSI.

> > So you agree a bit of spring cleaning wouldn't hurt, right? ;)
>
> Absolutely, and I have a catalogue of dust puppies to help that process ;-)

Okay. Let me first state that I do not really have the time to get
involved currently. ISDN4Linux and other pending kbuild stuff already
takes somewhat more than the remaining free time I have. But if you guys
want to get going with some step by step cleaning (w/o breaking too much),
I can try to help reviewing and submitting to Linus.

> > Well, you're right here. Which makes me think of my original idea as to
> > define all CONFIG_* values to "n" unless they've explicitly been assign
> > another value before.
>
> CML2's semantics were that all symbols have a default which is a zero; for
> booleans and tristates that means "n". Changing from those semantics to the
> ones necessary to run the gcml2 rulebase on CML1 rules was one of the most
> painful parts of supporting CML1.
>
> So I think having an explicit "n" default is a good idea, but I fail to see how
> you would actually implement such a thing in a shell based parser.

Basically, extend the "source" command to do a grep CONFIG_* in the file
to be read and set all found symbols to "n", if unset - only then do
the actual "source".

> > The main usage currently is "make oldconfig", though .config may be a bit
> > confusing: Questions which have been answered before (even with "n") will
> > not be asked again, whereas for undefined symbols, the corresponding
> > question is put.
> >
> > So I think the logic should really be tristate, "n","m","y", plus
> > additionally a list of CONFIG_* values which have been defined (as opposed
> > to just being "n" by default).
>
> This is precisely the CML2 semantics.
>
> > Of course, this is a 2.5 change,
>
> Agreed.
>
> > though the only potential for breakage
> > are the dep_* statements which are arguably already broken.
>
> I don't think there's any value to gratuitously breaking 2.4's config.
> That's the point of a "stable" series right?

I agree.

Anyway, some more points:

o a) dep_bool ' Blah' CONFIG_FOO $CONFIG_BAR vs.
b) dep_bool ' Blah' CONFIG_FOO CONFIG_BAR

(the latter proposed by Peter Samuelson)

I see the following:
b) needs a large scale patch through all Config.in's. OTOH, it can be
done step by step, only changing an instance after it has been looked
at. a) means only a patch to Configure/menuconfig etc, but since it
changes semantics, it'd be nice to check all possibly breaking usages
(not too hard thanks to gcml2)

I find a) more intuitive, for people who know sh, it's pretty clear
when we use "$" and when not. Also, for 'if' statements, we'll have to
use the "$" variant anyway for all I can see, so I prefer that from a
consistency point of view.

b) is better if you want to add features like automatic
"(EXPERIMENTAL)"

a) has the advantage of automatically getting rid of the ugly duplicated
'if' tests: (And I think it should allow for getting rid of the
quotation marks, too)

if [ "$CONFIG_FOO" = "" -o "$CONFIG_FOO" = "n" ]
--> if [ "$CONFIG_FOO" == "n" ]
if [ "$CONFIG_FOO" = "y" -o "$CONFIG_FOO" = "m" ]
--> if [ "$CONFIG_FOO" != "n" ]

o whatever we do, having a nice way to handle two exclusive drivers would
be nice

--Kai

2002-08-13 20:44:55

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

[Kai Germaschewski]
> Well, it'd be nice to first "fix" the dep_* statements so that they
> don't break when that change is done (i.e. in this case, moving
> IDESCSI behind CONFIG_SCSI.

Yes. That's my current plan.

> Basically, extend the "source" command to do a grep CONFIG_* in the
> file to be read and set all found symbols to "n", if unset - only
> then do the actual "source".

Ugly - I'd rather not have to do it that way. (:

> Anyway, some more points:
>
> o a) dep_bool ' Blah' CONFIG_FOO $CONFIG_BAR vs.
> b) dep_bool ' Blah' CONFIG_FOO CONFIG_BAR
>
> (the latter proposed by Peter Samuelson)
>
> I see the following:
> b) needs a large scale patch through all Config.in's. OTOH, it can be
> done step by step, only changing an instance after it has been looked
> at. a) means only a patch to Configure/menuconfig etc, but since it
> changes semantics, it'd be nice to check all possibly breaking usages
> (not too hard thanks to gcml2)

sed '/dep_/s/ \$CONFIG_/ CONFIG_/g' is quite effective. In any case
it is not hard to support both syntaxes - once the transition is
complete, or reasonably complete, we can change the semantics to
'n'=='', which in Configure/Menuconfig can only be enforced in the
non-$ case (well, unless we use your 'source' statement idea).

> I find a) more intuitive, for people who know sh, it's pretty
> clear when we use "$" and when not. Also, for 'if' statements,
> we'll have to use the "$" variant anyway for all I can see, so I
> prefer that from a consistency point of view.

The problem with "intuitive for people who know sh" is that people
think Config.in *is* shell. They start putting in constructs which
are not valid Config.in syntax but which *are* valid sh syntax, so
they work with certain parsers but not others.

Mutating the language, long-term, so that it looks less like sh and
more like a specialised language, is IMO a worthy goal. And I think
it can be done. The main thing to deal with is adding an alternative
syntax for 'if' statements which doesn't look like test(1). More
about that in a separate message.

> a) has the advantage of automatically getting rid of the ugly duplicated
> 'if' tests: (And I think it should allow for getting rid of the
> quotation marks, too)
>
> if [ "$CONFIG_FOO" = "" -o "$CONFIG_FOO" = "n" ]
> --> if [ "$CONFIG_FOO" == "n" ]
> if [ "$CONFIG_FOO" = "y" -o "$CONFIG_FOO" = "m" ]
> --> if [ "$CONFIG_FOO" != "n" ]

See above - 'if' is due for an overhaul as well.

> o whatever we do, having a nice way to handle two exclusive drivers would
> be nice

You mean the case where

A=y implies B=n
B=y implies A=n
A=m implies B<=m
B=m implies A<=m

I agree. Not sure if it needs special casing or just better general
facilities. I think it can be well served by the dep_* !CONFIG_FOO
patch, where !y==n, !n==y, !==y, and !m==m. Then

dep_tristate CONFIG_A !CONFIG_B
dep_tristate CONFIG_B !CONFIG_A

Peter

2002-08-14 00:18:39

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

Sam Ravnborg wrote:
>
> On Tue, Aug 13, 2002 at 01:23:19PM +1000, Greg Banks wrote:
> >
> > 977 missing-experimental-tag
> > 113 spurious-experimental-tag
> > 145 variant-experimental-tag
> > 30 inconsistent-experimental-tag
> > 13 missing-obsolete-tag
> > 41 spurious-obsolete-tag
> > 25 variant-obsolete-tag
> How about extending the language (side effect) to automagically append
> (EXPERIMENTAL) or (OBSOLETE) to the menu line, if dependent on
> those special tags?

Yes, this is obviously a good idea, and also it's what CML2 did.
Especially considering that (NEW) is automatically generated, and
(NEW) is not intuitively different from (EXPERIMENTAL) to the lay
user.

The trouble is actually achieving that in shell-based parsers where
shell code cannot tell whether $CONFIG_EXPERIMENTAL has been used in
a condition.

Greg.
--
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.

2002-08-14 01:23:10

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

Peter Samuelson wrote:
>
> [Kai Germaschewski]
>
> sed '/dep_/s/ \$CONFIG_/ CONFIG_/g' is quite effective. In any case
> it is not hard to support both syntaxes - once the transition is
> complete,

Does "complete" mean all the ports have also made the change and been merged back?

or reasonably complete, we can change the semantics to
> 'n'=='', which in Configure/Menuconfig can only be enforced in the
> non-$ case (well, unless we use your 'source' statement idea).

I don't think it's good policy to have the $ and non-$ cases behaving
differently if we can avoid it.

> > I find a) more intuitive, for people who know sh, it's pretty
> > clear when we use "$" and when not. Also, for 'if' statements,
> > we'll have to use the "$" variant anyway for all I can see, so I
> > prefer that from a consistency point of view.
>
> The problem with "intuitive for people who know sh" is that people
> think Config.in *is* shell. They start putting in constructs which
> are not valid Config.in syntax but which *are* valid sh syntax, so
> they work with certain parsers but not others.

Tell me about it ;-) Actually the incidence of this is low, presumably
someone comes along and reports an xconfig failure and the problem gets
fixed. I found only a half-dozen or so of these.

I'm more concerned about subtle dependencies on execution order resulting
from misuse of conditionals.

Greg.
--
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.

2002-08-14 01:39:01

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

[I wrote]
> > sed '/dep_/s/ \$CONFIG_/ CONFIG_/g' is quite effective. In any
> > case it is not hard to support both syntaxes - once the transition
> > is complete,

[Greg Banks]
> Does "complete" mean all the ports have also made the change and
> been merged back?

Either that, or, Linus gets tired of seeing mixed syntax in his tree,
does the 'sed' himself, and removes the compatibility parsing. Linus
has never been afraid to force the hand of a port maintainer.
Remember what happened to the old-style Rules.make syntax just before
2.4 went gold.

Actually I suspect it would be more like the C99 thing: after the new
syntax is added, we start doing [TRIVIAL] patches to clean out the
old, and eventually once that is done we have the option of removing
the old syntax or leaving it in as a known oddity. I'd favor removing
it, but people who maintain exarboralities for both 2.4 and 2.6 would
not thank me.

> I don't think it's good policy to have the $ and non-$ cases
> behaving differently if we can avoid it.

A good reason to excise the $ case from the tree at first opportunity.
Sure, it would cause complaints from people getting too many .rejs
from personal trees. But dang it, it's just one line of sed. (Or
'ed' / 'perl -wpi' for in situ editing, depending on whether or not
you're Al Viro.)

> I'm more concerned about subtle dependencies on execution order
> resulting from misuse of conditionals.

Yeah, that's the real reason 'n'!='' is Considered Harmful (and warned
about in the docs even now).

Peter

2002-08-14 02:22:30

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

Peter Samuelson wrote:
>
> [Greg Banks]
> > Does "complete" mean all the ports have also made the change and
> > been merged back?
> [...]
> Actually I suspect it would be more like the C99 thing: after the new
> syntax is added, we start doing [TRIVIAL] patches to clean out the
> old, and eventually once that is done we have the option of removing
> the old syntax or leaving it in as a known oddity. [...]

Fair enough.

> > I'm more concerned about subtle dependencies on execution order
> > resulting from misuse of conditionals.
>
> Yeah, that's the real reason 'n'!='' is Considered Harmful (and warned
> about in the docs even now).

There are issues regardless of the behaviour of "". For example, here's
one of at least 8 ways I've identified where things can go wrong when
conditionals are misused.

#
# Testing mixed overlap, type 1
# (mixed overlap, define first, query conditional, same menu)
#

mainmenu_option next_comment
comment 'xconfig needs this menu'

define_bool CONFIG_QUUX y

bool 'Set this symbol to ON' CONFIG_FOO

if [ "$CONFIG_FOO" = "y" ]; then
bool 'Here QUUX is a query symbol' CONFIG_QUUX
fi

endmenu

# Expected semantics:
# FOO=n => QUUX not asked, is y.
# FOO=y => QUUX asked, default y, can be either y or n.
# so list of valid configs is:
# QUUX=y FOO=n
# QUUX=y FOO=y
# QUUX=n FOO=y

# Actual semantics, "make config"
# FOO=n => QUUX not asked, is y (CORRECT)
# FOO=y => QUUX asked, default y,
# if y appears twice with same value (INCORRECT)
# if n appears twice with different values (INCORRECT)
# list of produced configs:
# QUUX=y FOO=n
# QUUX=y FOO=y QUUX=y
# QUUX=y FOO=y QUUX=n

# Actual semantics, "make menuconfig"
# FOO=n => QUUX not asked, is y (CORRECT)
# FOO=y => QUUX asked, default y,
# if y appears twice with same value (INCORRECT)
# cannot set to n (INCORRECT)
# list of produced configs:
# QUUX=y FOO=n
# QUUX=y FOO=y QUUX=y

# Actual semantics, "make xconfig"
# FOO=n => QUUX not asked
# on save, get "ERROR - Attempting to write value for unconfigured variable (CONFIG_QUUX)"
# does not save QUUX at all (INCORRECT)
# FOO=y => QUUX asked, default y,
# if y appears twice with same value (INCORRECT)
# cannot set to n (INCORRECT)
# list of produced configs:
# FOO=n
# QUUX=y FOO=y QUUX=y

Greg.
--
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.

2002-08-14 02:53:25

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

[Greg Banks]
> define_bool CONFIG_QUUX y
>
> bool 'Set this symbol to ON' CONFIG_FOO
>
> if [ "$CONFIG_FOO" = "y" ]; then
> bool 'Here QUUX is a query symbol' CONFIG_QUUX
> fi

It's (somewhat) well-known that things tend to fly apart when you try
to redefine a symbol. I don't see it documented, but I suppose it
should be. In any case, you're supposed to use "else" - see the
example in config-language.txt under "=== define_hex".

Peter

2002-08-14 04:45:51

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

On Wed, 14 Aug 2002, Greg Banks wrote:

> Peter Samuelson wrote:
> >
> > [Greg Banks]
> > > Does "complete" mean all the ports have also made the change and
> > > been merged back?
> > [...]
> > Actually I suspect it would be more like the C99 thing: after the new
> > syntax is added, we start doing [TRIVIAL] patches to clean out the
> > old, and eventually once that is done we have the option of removing
> > the old syntax or leaving it in as a known oddity. [...]

Well, I think when the switch does not change any behavior, it's actually
okay to get it over with in one large but trivial patch. The other
approach would be to give the new syntax the new behavior, and do the
actual switch piecemeal, checking and fixing dep_* statements as they get
converted.

It'd be nice to introduce a warning for statements where the old syntax is
used, but that seems not possible at least in Configure, since I think
statements like

dep_tristate '...' CONFIG_FOO m

should remain valid.

> #
> # Testing mixed overlap, type 1
> # (mixed overlap, define first, query conditional, same menu)
> #
>
> mainmenu_option next_comment
> comment 'xconfig needs this menu'
>
> define_bool CONFIG_QUUX y
>
> bool 'Set this symbol to ON' CONFIG_FOO
>
> if [ "$CONFIG_FOO" = "y" ]; then
> bool 'Here QUUX is a query symbol' CONFIG_QUUX
> fi
>
> endmenu

Well, it's a bug.

Setting CONFIG_QUUX to "y" when CONFIG_FOO is "n" can be done in
an else clause to the if statement. If you want to set a default, that's
what defconfig is for.

What's nice is that you identified so many problematic cases already, so
fixing shouldn't be hard. It may still make sense to add code to
"Configure" which recognizes a redefinition and complains or even aborts.

--Kai

2002-08-14 05:31:00

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

Kai Germaschewski wrote:
>
> On Wed, 14 Aug 2002, Greg Banks wrote:
>
> > Peter Samuelson wrote:
> > >
> > > [Greg Banks]
> > > > Does "complete" mean all the ports have also made the change and
> > > > been merged back?
> > > [...]
> > > Actually I suspect it would be more like the C99 thing: after the new
> > > syntax is added, we start doing [TRIVIAL] patches to clean out the
> > > old, and eventually once that is done we have the option of removing
> > > the old syntax or leaving it in as a known oddity. [...]
>
> Well, I think when the switch does not change any behavior, it's actually
> okay to get it over with in one large but trivial patch. The other
> approach would be to give the new syntax the new behavior, and do the
> actual switch piecemeal, checking and fixing dep_* statements as they get
> converted.

I tend to favour the piecemeal approach but I'm not particularly fussed as
long as it actually gets done.

> It'd be nice to introduce a warning for statements where the old syntax is
> used, but that seems not possible at least in Configure, since I think
> statements like
>
> dep_tristate '...' CONFIG_FOO m
>
> should remain valid.

In general it seems to me that adding useful warnings to shell-based parsers
is difficult.

> > define_bool CONFIG_QUUX y
> >
> > bool 'Set this symbol to ON' CONFIG_FOO
> >
> > if [ "$CONFIG_FOO" = "y" ]; then
> > bool 'Here QUUX is a query symbol' CONFIG_QUUX
> > fi
>
> Well, it's a bug.

Agreed, and there several of them in the CML1 corpus, some rather
obscure (e.g. the define and the query happen in different Config.in
files and only for some architectures).

> Setting CONFIG_QUUX to "y" when CONFIG_FOO is "n" can be done in
> an else clause to the if statement. If you want to set a default, that's
> what defconfig is for.

Yes.

> What's nice is that you identified so many problematic cases already, so
> fixing shouldn't be hard.

Like I said, I have a full catalogue of dust puppies ;-)

> It may still make sense to add code to
> "Configure" which recognizes a redefinition and complains or even aborts.

This would be a brutally effective way of forcing the problems to be fixed.

Greg.
--
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.

2002-08-14 11:37:28

[permalink] [raw]

Subject: Re: [patch] config language dep_* enhancements

Hi,

On Tue, 13 Aug 2002, Peter Samuelson wrote:

> Mutating the language, long-term, so that it looks less like sh and
> more like a specialised language, is IMO a worthy goal. And I think
> it can be done. The main thing to deal with is adding an alternative
> syntax for 'if' statements which doesn't look like test(1). More
> about that in a separate message.

That doesn't solve any of the more fundamental problems.
1) We still have 3 config parsers, which produce slightly different
.config files.
2) To integrate a new driver, you have to touch at least 3 files:
Config.in, Config.help, Makefile. Properly configuring and building a
driver outside of the tree is painful to impossible.

I'm not against fixing the bugs in the config scripts or adding some
small extensions, but if you want to "mutate" the language into something
different, I really hope you have a good plan for that.
The problems are really not simple, the current config language is very
limited, which also limits a bit the current error sources. As soon as you
add new features, you need to add better error checking, which will be
very painful in pure shell and keeping it consistent between multiple
parsers will also be interesting.
It's not the same problem area as with the build system. There we only
have a single Rules.make file. Normal users don't need to care much about
it. make was actually designed to build applications. The build system can
rely on correct information from the config system.
The build system was fixable within the capabilities of make, but the
config system involves a lot more complex system of various scripts and
programs. If you some great ideas to fix all the problems, I'd really like
to hear them.

bye, Roman

2002-08-14 20:01:44

by Sam Ravnborg

[permalink] [raw]

Subject: Get rid of shell based Config.in parsers?

On Wed, Aug 14, 2002 at 10:22:55AM +1000, Greg Banks wrote:
> The trouble is actually achieving that in shell-based parsers where
> shell code cannot tell whether $CONFIG_EXPERIMENTAL has been used in
> a condition.

Where comes the requirement that we shall keep the existing shell
based config parsers?

Remembering the CML2 war there were no serious objections about
shifting away from shell based parsers (but certainly a lot about the
alternative selected).

It is possible to replace Configure and menuconfig rather easy
and then see if a new xconfig showed up based on the new parsers.
This would allow us to do much more advanced semantic checks, and
give proper warnings to catch errors early.
The first versions should obviously not introduce new syntax, that
should evolve over time.

I dislike seeing arguments that this is not easy/possible in shell based
parsers. If the chosen technology does not fit the problem domain
then it's about time to shift technology.

Sam

2002-08-14 22:17:48