Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Adam J. Richter]

I am following up my own message here.

>>> = Adam Richter
>>  = Alan Cox
>   = Adam Richter

>>> 	Argh!  I just accidentally sent and older version of my
>>> patch.  Here is the current version.  Sorry about that.

>>This just breaks stuff

>>> +for var in $(cat arch/*/config.in |
>>> +	     egrep -w -v '^[ 	]*int' |
>>> +             tr '   $"' '\n\n\n' |
>>> +	     egrep '^CONFIG_[A-Z0-9_]*$' |
>>> +	     sort -u) ; do
>>> +	define_bool "$var" "n"
>>> +done
>>> +set -f
>>>  

>>You've changed the entire semantics of dep_tristate by doing this

>	Please provide a real example.

	Although I am curious about what you had in mind about
dep_tristate, I no longer need to see this example to see a problem
with my patch.  My patch breaks detection of "new" variables in
arch/*/config.in by "make oldconfig."

	So, I guess something like Keith Owens's patch would be the
way to go, with some additional definitions (CONFIG_AGP, CONFIG_PCI,
CONFIG_ISA, CONFIG_EISA, CONFIG_PCMCIA, and possibly others).  I am
not sure which other conditionals might also be incorrectly ignored by
some instances of dep_xxx.  Below, I have included a list of the 52
CONFIG_* variables that are used as arguments to dep_xxx in 2.4.6-pre6
and appear in arch/*/config.in.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

CONFIG_ACPI
CONFIG_AGP
CONFIG_AMIGA
CONFIG_ARCH_ACORN
CONFIG_ARCH_ARCA5K
CONFIG_ARCH_CLPS711X
CONFIG_ARCH_FOOTBRIDGE
CONFIG_ARCH_NETWINDER
CONFIG_ARCH_SA1100
CONFIG_ATARI
CONFIG_ATM
CONFIG_BLK_DEV_IDE
CONFIG_BLK_DEV_LOOP
CONFIG_BLK_DEV_RAM
CONFIG_BUSMOUSE
CONFIG_CPU_26
CONFIG_CPU_32
CONFIG_DEBUG_LL
CONFIG_DEVFS_FS
CONFIG_DRM
CONFIG_EISA
CONFIG_EXPERIMENTAL
CONFIG_FOOTBRIDGE
CONFIG_GVPIOEXT
CONFIG_IDE
CONFIG_IEEE1394
CONFIG_IEEE1394_OHCI1394
CONFIG_INPUT
CONFIG_ISA
CONFIG_ISDN
CONFIG_MAC
CONFIG_MCA
CONFIG_MD
CONFIG_MODULES
CONFIG_NET
CONFIG_PARPORT
CONFIG_PCI
CONFIG_PCMCIA
CONFIG_PM
CONFIG_PPP
CONFIG_PROC_FS
CONFIG_SA1100_ASSABET
CONFIG_SBUS
CONFIG_SCSI
CONFIG_SERIAL
CONFIG_SGI
CONFIG_SOUND
CONFIG_SPARC64
CONFIG_UNIX98_PTYS
CONFIG_VIDEO_DEV
CONFIG_X86
CONFIG_ZORRO

Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Russell King]

On Sat, Jun 30, 2001 at 07:57:10AM -0700, Adam J. Richter wrote:
> 	So, I guess something like Keith Owens's patch would be the
> way to go, with some additional definitions (CONFIG_AGP, CONFIG_PCI,
> CONFIG_ISA, CONFIG_EISA, CONFIG_PCMCIA, and possibly others).  I am
> not sure which other conditionals might also be incorrectly ignored by
> some instances of dep_xxx.  Below, I have included a list of the 52
> CONFIG_* variables that are used as arguments to dep_xxx in 2.4.6-pre6
> and appear in arch/*/config.in.

I have confirmed that Keith Owens patch doesn't work with xconfig - you
can't select any option which has been define_bool'd to 'n'.

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

Re: 2.4.6p6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Riley Williams]

Hi Russell, Adam.

 >> So, I guess something like Keith Owens's patch would be the way
 >> to go, with some additional definitions (CONFIG_AGP, CONFIG_PCI,
 >> CONFIG_ISA, CONFIG_EISA, CONFIG_PCMCIA, and possibly others).
 >> I am not sure which other conditionals might also be incorrectly
 >> ignored by some instances of dep_xxx.  Below, I have included a
 >> list of the 52 CONFIG_* variables that are used as arguments to
 >> dep_xxx in 2.4.6-pre6 and appear in arch/*/config.in.

 > I have confirmed that Keith Owens patch doesn't work with
 > xconfig - you can't select any option which has been
 > define_bool'd to 'n'.

I've followed this thread with interest, and think I've followed both
sides of the argument, so can I summarise:

 1. Adam's point is that there are dep_* statements in the config
    setup that have been used to say that a particular option is
    dependant upon a particular architecture, but this doesn't work.

 2. Russell's point is that Adam's point is correct, but the patch
    that Adam submitted can't be used as it breaks other things.

 3. MY understanding of the situation is that ALL architecture
    specific config lines are EXPECTED to be in the arch/*/config.in
    files, where they will only even be seen when the relevant
    architecture is being compiled for.

As a result of this, I would summarise this discussion as saying that
there is a bug in the kernel config scripts in that some options that
should be located in the architecture-specific config files are in the
all-architecture config files instead.

Best wishes from Riley.

Re: 2.4.6p6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Keith Owens]

On Sat, 30 Jun 2001 21:36:26 +0100 (BST), 
Riley Williams <rhw@MemAlpha.CX> wrote:
> 1. Adam's point is that there are dep_* statements in the config
>    setup that have been used to say that a particular option is
>    dependant upon a particular architecture, but this doesn't work.
>
> 3. MY understanding of the situation is that ALL architecture
>    specific config lines are EXPECTED to be in the arch/*/config.in
>    files, where they will only even be seen when the relevant
>    architecture is being compiled for.
>
>As a result of this, I would summarise this discussion as saying that
>there is a bug in the kernel config scripts in that some options that
>should be located in the architecture-specific config files are in the
>all-architecture config files instead.

(1) and (3) are correct but your conclusion is not.  The problem is

  dep_tristate CONFIG_some_driver $CONFIG_some_arch

where the intention is to allow the driver only if some_arch is set.
When you compile for some_other_arch, CONFIG_some_arch is undefined.
dep_tristate treats undefined variables as "don't care" and we cannot
fix that without changing bash or a major rewrite of the shell scripts.
There are two solutions, either change all such lines to

  if [ "$CONFIG_some_arch" = "y" ];then
    tristate CONFIG_some_driver
  fi

or

  define_bool CONFIG_some_arch n

for all architectures at the start, followed by turning on the one that
is required.

Lots of if statements are messy and they will not prevent somebody
adding new options with exactly the same problem.  Explicitly setting
all but one arch variable to 'n' results in cleaner config scripts and
new arch dependent driver settings will automatically work.

[PATCH] Re: 2.4.6p6: dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Riley Williams]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4360 bytes --]

Hi Keith.

I don't agree with your analysis in the first block quoted below, but
that's not relevant as I feel there's a better solution than either of
the ones proposed so far. See below for details...

 >> 1. Adam's point is that there are dep_* statements in the config
 >>    setup that have been used to say that a particular option is
 >>    dependant upon a particular architecture, but this doesn't work.
 >>
 >> 3. MY understanding of the situation is that ALL architecture
 >>    specific config lines are EXPECTED to be in the arch/*/config.in
 >>    files, where they will only even be seen when the relevant
 >>    architecture is being compiled for.
 >>
 >> As a result of this, I would summarise this discussion as saying
 >> that there is a bug in the kernel config scripts in that some
 >> options that should be located in the architecture-specific
 >> config files are in the all-architecture config files instead.

 > (1) and (3) are correct but your conclusion is not. The problem is
 >
 >   dep_tristate CONFIG_some_driver $CONFIG_some_arch
 >
 > where the intention is to allow the driver only if some_arch is
 > set.

Can I suggest you re-read your comment and the points you quoted and
said are correct. As a DIRECT logical consequence of "(1) and (3) are
correct" (as you phrased it), we get the conclusion that any config
lines that depend on "if some arch is set" (as you phrased it) are in
the architecture-specific config files. This leads DIRECTLY to the
conclusion that ANY lines dependant on a particular architecture that
are not in the architecture-specific config files are a bug in the
kernel config scripts.

=======================================================================

Personally, I would suggest that the bug in this case is the actual
assumption that (3) is true, and the correct course of action is to
remove that assumption as it leads directly to the spaghetti in the
configuration system that we currently have.

 > When you compile for some_other_arch, CONFIG_some_arch is
 > undefined. dep_tristate treats undefined variables as "don't
 > care"...

Agreed - and whoever did the config lines where the dependancy is an
arch variable made the mistake of misunderstanding that.

 > ...and we cannot fix that without changing bash or a major
 > rewrite of the shell scripts.

Why is either needed? As I see it, the cure is to define a pair of new
statement types in the config language, as follows:

 1. dep_arch_bool CONFIG_var CONFIG_arch [CONFIG_other_var...]

    This states that CONFIG_var is a boolean var that depends both on
    CONFIG_arch being specifically "y" and on CONFIG_other_var being
    such as to satisfy dep_bool as currently.

 2. dep_arch_tristate CONFIG_var CONFIG_arch [CONFIG_other_var...]

    This is the tristate version of dep_arch_bool as expected.

When we've done that, ALL of the problem lines can be trivially
converted from dep_ to dep_arch_ and the problem vanishes. As a free
bonus, the need for the arch-specific config files vanishes as well,
and each option can be documented as to what architectures it is valid
for. This thus removes a possible source of bugs from the equation.

The enclosed patch (against 2.4.5 raw) adds these two statements to
both the `make config` and `make menuconfig` scripts. I don't
understand TCL/TK so can't add them to the `make xconfig` script, and
as I also don't understand PERL, I can't add it to `make checkconfig`
so somebody else will need to deal with those two scripts.

 > There are two solutions, either change all such lines to
 >
 >   if [ "$CONFIG_some_arch" = "y" ];then
 >     tristate CONFIG_some_driver
 >   fi
 >
 > or
 >
 >   define_bool CONFIG_some_arch n
 >
 > for all architectures at the start, followed by turning on the
 > one that is required.

Both are messy, and best described as kludges. I wouldn't support
either.

 > Lots of if statements are messy and they will not prevent
 > somebody adding new options with exactly the same problem.

Agreed.

 > Explicitly setting all but one arch variable to 'n' results in
 > cleaner config scripts and new arch dependent driver settings
 > will automatically work.

Until somebody adds a new port and fails to upgrade any one of the
various files doing this. That's an open recipe for bugs IMHO, and
should be avoided at all costs.

Best wishes from Riley.

[-- Attachment #2: Configure and Menuconfig patch --]
[-- Type: APPLICATION/x-gzip, Size: 1137 bytes --]

Re: [PATCH] Re: 2.4.6p6: dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Keith Owens]

On Mon, 2 Jul 2001 00:04:22 +0100 (BST), 
Riley Williams <rhw@MemAlpha.CX> wrote:
>Can I suggest you re-read your comment and the points you quoted and
>said are correct. As a DIRECT logical consequence of "(1) and (3) are
>correct" (as you phrased it), we get the conclusion that any config
>lines that depend on "if some arch is set" (as you phrased it) are in
>the architecture-specific config files. This leads DIRECTLY to the
>conclusion that ANY lines dependant on a particular architecture that
>are not in the architecture-specific config files are a bug in the
>kernel config scripts.

No.  We want network drivers to be in the network menu, SCSI drivers in
the SCSI menu etc.  Some of those drivers are restricted to some
architectures but putting them in the arch config splits the logical
flow of selection and duplicates text.  Look at the repeated SCSI code
in some of the arch configs.

> 2. dep_arch_tristate CONFIG_var CONFIG_arch [CONFIG_other_var...]

dep_arch_tristate '  AM79C961A support' CONFIG_ARM_AM79C961A $CONFIG_ARCH_ACORN $CONFIG_NET_ETHERNET

fails your code.  $CONFIG_ARCH_ACORN is undefined, $CONFIG_NET_ETHERNET
is 'y'.  dep_arch_tristate is invoked with 3 (not 4 parameters), text,
CONFIG_ARM_AM79C961A and 'y'.  The intervening undefined variable
disappears in shell scripts.

Re: [PATCH] Re: 2.4.6p6: dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Riley Williams]

Hi Keith.

 >> Can I suggest you re-read your comment and the points you quoted
 >> and said are correct. As a DIRECT logical consequence of "(1)
 >> and (3) are correct" (as you phrased it), we get the conclusion
 >> that any config lines that depend on "if some arch is set" (as
 >> you phrased it) are in the architecture-specific config files.
 >> This leads DIRECTLY to the conclusion that ANY lines dependant
 >> on a particular architecture that are not in the
 >> architecture-specific config files are a bug in the kernel
 >> config scripts.

 > No.  We want network drivers to be in the network menu, SCSI
 > drivers in the SCSI menu etc.  Some of those drivers are
 > restricted to some architectures but putting them in the arch
 > config splits the logical flow of selection and duplicates text.
 > Look at the repeated SCSI code in some of the arch configs.

That's a direct consequence of the policy quoted in paragraph (3) and
NOT an error in the logic. It's why I'm against the current policy.

 >> 2. dep_arch_tristate CONFIG_var CONFIG_arch [CONFIG_other_var...]

 > dep_arch_tristate ' AM79C961A support' CONFIG_ARM_AM79C961A \
 >	$CONFIG_ARCH_ACORN $CONFIG_NET_ETHERNET

 > fails your code.  $CONFIG_ARCH_ACORN is undefined,
 > $CONFIG_NET_ETHERNET is 'y'.  dep_arch_tristate is invoked with
 > 3 (not 4 parameters), text, CONFIG_ARM_AM79C961A and 'y'.  The
 > intervening undefined variable disappears in shell scripts.

You're not thinking clearly. Try the following simple fix to that:

 Q> dep_arch_tristate '  AM79C961A support' CONFIG_ARM_AM79C961A \
 Q>	"$CONFIG_ARCH_ACORN" $CONFIG_NET_ETHERNET

That adds only two extra characters, neither conspicuous, and PASSES
my code.

Best wishes from Riley.

Re: [PATCH] Re: 2.4.6p6: dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Keith Owens]

On Mon, 2 Jul 2001 08:16:50 +0100 (BST), 
Riley Williams <rhw@MemAlpha.CX> wrote:
> Q> dep_arch_tristate '  AM79C961A support' CONFIG_ARM_AM79C961A \
> Q>	"$CONFIG_ARCH_ACORN" $CONFIG_NET_ETHERNET
>
>That adds only two extra characters, neither conspicuous, and PASSES
>my code.

It relies on everybody writing new dep_arch_... rules to remember the
quotes.  You are just introducing another source of human error.  That
is how this mess occurred, no automatic validation of input.

Re: [PATCH] Re: 2.4.6p6: dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Riley Williams]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1125 bytes --]

Hi Keith.

 >> Q> dep_arch_tristate '  AM79C961A support' CONFIG_ARM_AM79C961A \
 >> Q>	"$CONFIG_ARCH_ACORN" $CONFIG_NET_ETHERNET

 >> That adds only two extra characters, neither conspicuous, and
 >> PASSES my code.

 > It relies on everybody writing new dep_arch_... rules to
 > remember the quotes.  You are just introducing another source of
 > human error.  That is how this mess occurred, no automatic
 > validation of input.

OK then, a simple change to the patch I submitted, and the following
instead...

 Q> dep_arch_tristate '  AM79C961A support' CONFIG_ARM_AM79C961A \
 Q>	ACORN $CONFIG_NET_ETHERNET

The enclosed patch implements this syntax, and CHECKS that the syntax
stated has been supplied, for both `make config` and `make menuconfig`
and I would imagine the same would be easily added to `make xconfig`
and `make checkconfig` as well by those fluent in the relevant
languages.

Note specifically that it requires that the CONFIG_ARCH_ part of the
name of the variable is NOT provided, and as a result requires that
config variables naming the architecture begin with that string.

Best wishes from Riley.

[-- Attachment #2: Patch v2 --]
[-- Type: APPLICATION/x-gzip, Size: 1555 bytes --]

Re: [PATCH] Re: 2.4.6p6: dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Russell King]

On Mon, Jul 02, 2001 at 09:25:50AM +0100, Riley Williams wrote:
>  Q> dep_arch_tristate '  AM79C961A support' CONFIG_ARM_AM79C961A \
>  Q>	ACORN $CONFIG_NET_ETHERNET

Before we go and create a patch for Linus to apply, please note that the
above is totally bogus and is in fact 100% wrong.  Don't create a patch
yourself.  Let me know how you propose to do it, and I will create the
patch using the correct symbols.

Also note that the majority of the machine-dependent symbols for StrongARM
platforms (of which there are around 43) start CONFIG_SA1100_*, not
CONFIG_ARCH_*.  Unfortunately, its far too late to get around this
special case (I'm not too happy that we have this special case either,
so don't whinge at me please).

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

Re: [PATCH] Re: 2.4.6p6: dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Riley Williams]

Hi Russell.

 >> Q> dep_arch_tristate '  AM79C961A support' CONFIG_ARM_AM79C961A \
 >> Q>		ACORN $CONFIG_NET_ETHERNET

 > Before we go and create a patch for Linus to apply...

Who's sent a patch to Linus? I haven't, and don't intend to do so.

 > ...please note that the above is totally bogus and is in fact
 > 100% wrong.

Please explain? I don't see the problem with the proposed syntax, and
presume you have noticed that it's a new statement type, not a
modification to an existing one?

 > Don't create a patch yourself. Let me know how you propose to do
 > it, and I will create the patch using the correct symbols.

OK, here's the proposal:

 1. Define new config statements that take as their parameters the
    following:

	1. The prompt text.

	2. The name of the config variable to set.

	3. The NAME of the config variable that defines the
	   required architecture.

	4. The VALUES of all other config variables this variable
	   depends on.

 2. Define the new `dep_arch_bool` statement to be the same as
    `dep_bool` if passed items 1, 2 and 4 when the config var
    named in item 3 has the value "y". When the config var named
    has any other value, it becomes `define_bool "$2" "n" instead.

 3. Define the new `dep_arch_tristate` similarly.

 > Also note that the majority of the machine-dependent symbols for
 > StrongARM platforms (of which there are around 43) start
 > CONFIG_SA1100_*, not CONFIG_ARCH_*.  Unfortunately, its far too
 > late to get around this special case (I'm not too happy that we
 > have this special case either, so don't whinge at me please).

First, why is it "far too late" as you put it? It won't be the first
time config vars have been renamed, and it's unlikely to be the last
either...

Secondly, that isn't a problem to this proposal. The reason for taking
the CONFIG_ARCH_ out of the syntax is to emphasise that it's the name
and not the value that goes in there, thus reducing the likelihood of
problems creeping in in the first place.

Best wishes from Riley.

Re: [PATCH] Re: 2.4.6p6: dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Russell King]

On Mon, Jul 02, 2001 at 01:40:25PM +0100, Riley Williams wrote:
> Who's sent a patch to Linus? I haven't, and don't intend to do so.

The way this thread is progressing, it won't take much to get there.  We've
already propagated the inaccuracies in the "example" depencencies by 3 or
more mails.  I'm just trying to stop it before someone forgets that it's
just an example.

> First, why is it "far too late" as you put it? It won't be the first
> time config vars have been renamed, and it's unlikely to be the last
> either...

I'm not going to cause disruption across the board to lots of people just
because someone wants to keep the length of the symbols down.

If you really do want to do this change, then I suggest that you get in
touch with Nicolas Pitre and discuss it with him.  When you come to a
conclusion, its not as simple as patching the kernel.  You need to
update the database at www.arm.linux.org.uk/developer/machines/ to
reflect the new symbols _at the same time_ that you change them in
everyones tree, since anyone can pull down a new copy of the symbols
from the database at any time.

IMHO, a logistical nightmare to perform.

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

Re: [PATCH] Re: 2.4.6p6: dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Nicolas Pitre]

On Mon, 2 Jul 2001, Russell King wrote:

> > First, why is it "far too late" as you put it? It won't be the first
> > time config vars have been renamed, and it's unlikely to be the last
> > either...

Can we just break everything apart in 2.5 please?  Will this still be an
issue with CML2 anyway?

> I'm not going to cause disruption across the board to lots of people just
> because someone wants to keep the length of the symbols down.
>
> If you really do want to do this change, then I suggest that you get in
> touch with Nicolas Pitre and discuss it with him.  When you come to a
> conclusion, its not as simple as patching the kernel.  You need to
> update the database at www.arm.linux.org.uk/developer/machines/ to
> reflect the new symbols _at the same time_ that you change them in
> everyones tree, since anyone can pull down a new copy of the symbols
> from the database at any time.

For instance we might just keep the SA1100 out of the picture until we're
ready to make such change as "atomic" as possible for all people involved.


Nicolas

Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Keith Owens]

On Sat, 30 Jun 2001 16:01:01 +0100, 
Russell King <rmk@arm.linux.org.uk> wrote:
>I have confirmed that Keith Owens patch doesn't work with xconfig - you
>can't select any option which has been define_bool'd to 'n'.

My patch only define_bool's the arch variables.  None of those are
selectable.

Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Adam J. Richter]

>> 	Argh!  I just accidentally sent and older version of my
>> patch.  Here is the current version.  Sorry about that.

>This just breaks stuff

>> +for var in $(cat arch/*/config.in |
>> +	     egrep -w -v '^[ 	]*int' |
>> +             tr '   $"' '\n\n\n' |
>> +	     egrep '^CONFIG_[A-Z0-9_]*$' |
>> +	     sort -u) ; do
>> +	define_bool "$var" "n"
>> +done
>> +set -f
>>  

>You've changed the entire semantics of dep_tristate by doing this

	Please provide a real example.

	As far as I can tell, the only change would be to make
dep_tristate behave the way it was expected to, as in
drives/sound/Config.in:

      dep_tristate '    Netwinder WaveArtist' CONFIG_SOUND_WAVEARTIST $CONFIG_SOUND_OSS $CONFIG_ARCH_NETWINDER

	The current, unintended, behavior is to allow this module to be
built all all non-ARM architectures (and probably bomb out), as well
as the intended architecture of ARM-Netwinder, and not any other ARM
platforms.  The intended behavior, and the one that you would get with
either my change or Keith's is to only allow this module to be built
for ARM-Netwinder.


Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Adam J. Richter]

>From: Russell King <rmk@arm.linux.org.uk>
>On Sat, Jun 30, 2001 at 08:26:22AM +0100, Alan Cox wrote:
>> #2
>> 	dep_tristate $FOO $BAR
>> 
>> to say 'FOO requires BAR and must be a similar setting _IF_CONFIGURED_'

>Err, how can $BAR be undefined?  Configure sets all config variables which
>are answered with 'n' to 'n'.

One example would be processing of the following line on a non-sparc
computer (from linux-2.4.6-pre6/drivers/sbus/audio/Config.in):

dep_tristate '  Sun Microsystems userflash support' CONFIG_MTD_SUN_UFLASH $CONFIG_SPARC64

I think this could also come up for drivers that depend on
$CONFIG_ISA when configured for non-PC platforms that do not ask
about ISA support.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Adam J. Richter]

	Argh!  I just accidentally sent and older version of my
patch.  Here is the current version.  Sorry about that.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."
--------------------------CUT HERE----------------------------------
--- linux-2.4.6-pre6/scripts/Configure	Sat Dec 30 18:16:13 2000
+++ linux/scripts/Configure	Fri Jun 29 21:39:24 2001
@@ -48,6 +48,10 @@
 #
 # 24 January 1999, Michael Elizabeth Chastain, <mec@shout.net>
 # - Improve the exit message (Jeff Ronne).
+#
+# 29 June 2001, Adam J. Richter, <adam@yggdrasil.com>
+# - Default all non-numeric variables arch/*/config.in to "n"
+
 
 #
 # Make sure we're really running bash.
@@ -531,6 +535,18 @@
 echo " * Automatically generated C config: don't edit" >> $CONFIG_H
 echo " */" >> $CONFIG_H
 echo "#define AUTOCONF_INCLUDED" >> $CONFIG_H
+
+# Ensure all unselected architecture variables are set to "n" rather than being
+# undefined, so that dep_bool and dep_tristate properly detect their absense.
+set +f
+for var in $(cat arch/*/config.in |
+	     egrep -w -v '^[ 	]*int' |
+             tr '   $"' '\n\n\n' |
+	     egrep '^CONFIG_[A-Z0-9_]*$' |
+	     sort -u) ; do
+	define_bool "$var" "n"
+done
+set -f
 
 DEFAULT=""
 if [ "$1" = "-d" ] ; then

Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Alan Cox]

> 	Argh!  I just accidentally sent and older version of my
> patch.  Here is the current version.  Sorry about that.

This just breaks stuff

> +for var in $(cat arch/*/config.in |
> +	     egrep -w -v '^[ 	]*int' |
> +             tr '   $"' '\n\n\n' |
> +	     egrep '^CONFIG_[A-Z0-9_]*$' |
> +	     sort -u) ; do
> +	define_bool "$var" "n"
> +done
> +set -f
>  

You've changed the entire semantics of dep_tristate by doing this

Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Adam J. Richter]

>> = Keith Owens
>  = Alan Cox

>> I'd rather that we fixed dep_* so that undefined symbols were treated as
>> 'n', just like the makefiles treat undefined symbols.
>
>That isnt a simple change. dep_tristate is used both to express 'need this'
>and also 'conflicts with'. Those are ambiguous. You'd need to extend the
>syntax say by adding  ${FOO:N} syntax 

	I do not understand what you (Alan) mean by the "'conflicts with'"
usage.  I do not believe there is any way to directly use dep_* to express
that a "y" answer to some feature requires "n" or even "m" for another
feature.

	Regarding Jeff Garzik's suggestion to just "Define CONFIG_ARCH_xxx
in various arches where needed", the problem primarily arises from
CONFIG_ variables from other architectures, so you're talking about
adding the same set of lines for every architecture, and they are
changes that would have to be maintained.  That wouldn't be the
end of the world, but it would be another instance of people doing
work that computers can do for them.

	Implementing Keith's suggestion will still require changes to
the Config.in files, to put quotation marks around things like
$CONFIG_SPARC64.  Otherwise, the shell will treat the undefined
variable is if it were not provided, as opposed to turning it into
an emptry string argument.  I could put together a patch to do this
if there is a consensus that it is the preferred solution.

	In the meantime, I have implemented the following small kludge
in scripts/Configure that extracts all variables from arch/*/config.in
and sets them all to "n" before reading in their default values.
I only processed the variables in arch/*/config.in so that I could
assume that the list of variables is small and because defaulting the
variables to "n" makes it slightly harder to detect bugs where Config.in
scripts look at the values of variables that have not yet been set.
Because some platforms use variables that do not being with CONFIG_ARCH
(e.g., CONFIG_SPARC64, CONFIG_X86), I could not just filter for CONFIG_ARCH_*.
I could mail Linus a shell script to clean this up too if that were
desired (a patch would be far too messy).  Anyhow, the change seems to
work, although I have been bumping into a lot of other build errors
with linux-2.4.6-pre6, partly as a result of gcc-3.0 pickiness, so
I have yet to see the build complete.  It is a kludge, but at least
it's a solution.  I'm not particularly enamored of any one approach
in this case; I just want it resolved in a way that is unlikely to
lead to recurrence.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."


--- linux-2.4.6-pre6/scripts/Configure	Sat Dec 30 18:16:13 2000
+++ linux/scripts/Configure	Fri Jun 29 15:18:14 2001
@@ -48,6 +48,9 @@
 #
 # 24 January 1999, Michael Elizabeth Chastain, <mec@shout.net>
 # - Improve the exit message (Jeff Ronne).
+#
+# 29 June 2001, Adam J. Richter, <adam@yggdrasil.com>
+# - Default all CONFIG_ARCH_* and CONFIG_X86 to "n"
 
 #
 # Make sure we're really running bash.
@@ -531,6 +534,16 @@
 echo " * Automatically generated C config: don't edit" >> $CONFIG_H
 echo " */" >> $CONFIG_H
 echo "#define AUTOCONF_INCLUDED" >> $CONFIG_H
+
+# Ensure all unselected architectures are set to "n" rather than being
+# undefined, so that dep_bool and dep_tristate properly detect their absense.
+# Really, CONFIG_X86 should be CONFIG_ARCH_X86.
+set +f
+for arch in CONFIG_X86 $(cat arch/*/config.in | tr '   $"' '\n\n\n' |
+              egrep ^CONFIG_ARCH_ | sort -u) ; do
+	define_bool "$arch" "n"
+done
+set -f
 
 DEFAULT=""
 if [ "$1" = "-d" ] ; then

Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Alan Cox]

> 	I do not understand what you (Alan) mean by the "'conflicts with'"
> usage.  I do not believe there is any way to directly use dep_* to express
> that a "y" answer to some feature requires "n" or even "m" for another
> feature.

Uses for dep_tristate

#1

	dep_tristate $FOO $BAR

to say 'FOO requires BAR and must be a similar setting'


#2
	dep_tristate $FOO $BAR

to say 'FOO requires BAR and must be a similar setting _IF_CONFIGURED_'

Think about Plug and Play

A driver needs to be modular if PnP is modular, but with a non PnP kernel
can be Yes even if PNP is off. 

Alan

Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Russell King]

On Sat, Jun 30, 2001 at 08:26:22AM +0100, Alan Cox wrote:
> #2
> 	dep_tristate $FOO $BAR
> 
> to say 'FOO requires BAR and must be a similar setting _IF_CONFIGURED_'

Err, how can $BAR be undefined?  Configure sets all config variables which
are answered with 'n' to 'n'.

Therefore, if you do:

bool 'PNP?' PNP

dep_tristate 'FOO?' FOO $PNP

and you answer 'n' to PNP, then FOO will be 'n'.

Can you extract an example where #2 is actually used?

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

Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Alan Cox]

> Err, how can $BAR be undefined?  Configure sets all config variables which
> are answered with 'n' to 'n'.

Welcome to the 'if' statement....

> Can you extract an example where #2 is actually used?

>From a first review I can't - but we need to verify that is the case completely
before we make the change.

Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Russell King]

On Sat, Jun 30, 2001 at 12:43:54PM +0100, Alan Cox wrote:
> > Err, how can $BAR be undefined?  Configure sets all config variables which
> > are answered with 'n' to 'n'.
> 
> Welcome to the 'if' statement....

Thank you, yes, but I believe we were talking about dep_* and not if
statements?

> From a first review I can't - but we need to verify that is the case
> completely before we make the change.

Indeed.

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

Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Alan Cox]

> > > Err, how can $BAR be undefined?  Configure sets all config variables which
> > > are answered with 'n' to 'n'.
> > 
> > Welcome to the 'if' statement....
> Thank you, yes, but I believe we were talking about dep_* and not if
> statements?

No we are talking about Config.in scripts

	if [ condition ]
		bool 'foo' CONFIG_FOO

	fi

	dep_tristate ... $CONFIG_FOO

> 

Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Russell King]

On Sat, Jun 30, 2001 at 01:01:18PM +0100, Alan Cox wrote:
> No we are talking about Config.in scripts

No.  My comment was in reply to your specific case 2 of dep_tristate.
There were no if statements in there.

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

Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Keith Owens]

On Sat, 30 Jun 2001 10:20:24 +0100, 
Russell King <rmk@arm.linux.org.uk> wrote:
>Err, how can $BAR be undefined?  Configure sets all config variables which
>are answered with 'n' to 'n'.

if [ "$CONFIG_xyz" = "y" ]; then
  bool CONFIG_bar
fi

CONFIG_bar can be undefined, not 'n'.  While that can cause problems,
it is also valid config code.  If I interpret AC's cryptic comments
correctly, there may be code which assumes that undefined variables are
just that, undefined.  Setting all variables to 'n' initially by Adam's
script will break such code.

This type of code treats undefined variables as "don't care", not as
"forbidden".  Is there any such code?  I don't know for sure, but I am
sure that a change of this magnitude does not belong in 2.4.

The problem Adam was trying to fix was

  dep_bool CONFIG_bar $CONFIG_ARCH_foo

where if the arch is not foo then bar is incorrectly allowed because
CONFIG_ARCH_foo is undefined.  IMHO it is safe to assume that all arch
dependent config settings are meant to be off if the arch is not
selected, i.e. setting CONFIG_ARCH_foo=n for all arch except the
current one is safe.  Setting _all_ CONFIG_foo=n for all variables is
not safe.

I still think this is the best approach, against 2.4.5-ac22.

Index: 5.54/arch/config.in
--- 5.54/arch/config.in Sat, 30 Jun 2001 21:43:30 +1000 kaos ()
+++ 5.54(w)/arch/config.in Sat, 30 Jun 2001 21:42:15 +1000 kaos (linux-2.4/D/e/15_config.in  644)
@@ -0,0 +1,21 @@
+# Ensure that all arch settings are off except the one that is selected.  This
+# simplifies arch dependent driver selection.  Each architecture's specific
+# config variable must appear in this list.  All arch's must include this file
+# at the start of arch/*/config.in.
+
+define_bool CONFIG_ALPHA n
+define_bool CONFIG_ARCH_CRIS n
+define_bool CONFIG_ARCH_M68K n
+define_bool CONFIG_ARCH_S390 n
+define_bool CONFIG_ARCH_S390X n
+define_bool CONFIG_ARM n
+define_bool CONFIG_IA64 n
+define_bool CONFIG_MIPS n
+define_bool CONFIG_MIPS_64 n
+define_bool CONFIG_PARISC n
+define_bool CONFIG_PPC n
+define_bool CONFIG_SPARC32 n
+define_bool CONFIG_SPARC64 n
+define_bool CONFIG_SUPERH n
+define_bool CONFIG_USERMODE n
+define_bool CONFIG_X86 n
Index: 5.54/arch/parisc/config.in
--- 5.54/arch/parisc/config.in Sun, 22 Apr 2001 08:14:43 +1000 kaos (linux-2.4/l/c/33_config.in 1.1.2.1 644)
+++ 5.54(w)/arch/parisc/config.in Sat, 30 Jun 2001 21:27:43 +1000 kaos (linux-2.4/l/c/33_config.in 1.1.2.1 644)
@@ -3,6 +3,8 @@
 # see the Configure script.
 #
 
+source arch/config.in
+
 mainmenu_name "Linux Kernel Configuration"
 
 define_bool CONFIG_PARISC y
Index: 5.54/arch/s390/config.in
--- 5.54/arch/s390/config.in Sun, 22 Apr 2001 08:14:43 +1000 kaos (linux-2.4/n/c/39_config.in 1.4 644)
+++ 5.54(w)/arch/s390/config.in Sat, 30 Jun 2001 21:27:50 +1000 kaos (linux-2.4/n/c/39_config.in 1.4 644)
@@ -3,6 +3,8 @@
 # see Documentation/kbuild/config-language.txt.
 #
 
+source arch/config.in
+
 define_bool CONFIG_ISA n
 define_bool CONFIG_EISA n
 define_bool CONFIG_MCA n
Index: 5.54/arch/mips64/config.in
--- 5.54/arch/mips64/config.in Wed, 20 Jun 2001 13:07:10 +1000 kaos (linux-2.4/p/c/34_config.in 1.2.1.1.1.2 644)
+++ 5.54(w)/arch/mips64/config.in Sat, 30 Jun 2001 21:42:08 +1000 kaos (linux-2.4/p/c/34_config.in 1.2.1.1.1.2 644)
@@ -2,6 +2,11 @@
 # For a description of the syntax of this configuration file,
 # see Documentation/kbuild/config-language.txt.
 #
+
+source arch/config.in
+
+define_bool CONFIG_ARCH_MIPS64 y
+
 mainmenu_name "Linux Kernel Configuration"
 
 mainmenu_option next_comment
Index: 5.54/arch/ia64/config.in
--- 5.54/arch/ia64/config.in Sun, 22 Apr 2001 07:25:55 +1000 kaos (linux-2.4/s/c/38_config.in 1.1.2.1.3.1.1.2 644)
+++ 5.54(w)/arch/ia64/config.in Sat, 30 Jun 2001 21:29:08 +1000 kaos (linux-2.4/s/c/38_config.in 1.1.2.1.3.1.1.2 644)
@@ -1,3 +1,5 @@
+source arch/config.in
+
 mainmenu_name "Kernel configuration of Linux for IA-64 machines"
 
 mainmenu_option next_comment
Index: 5.54/arch/sh/config.in
--- 5.54/arch/sh/config.in Fri, 29 Jun 2001 11:31:04 +1000 kaos (linux-2.4/t/c/42_config.in 1.1.1.1.1.1 644)
+++ 5.54(w)/arch/sh/config.in Sat, 30 Jun 2001 21:29:32 +1000 kaos (linux-2.4/t/c/42_config.in 1.1.1.1.1.1 644)
@@ -2,6 +2,9 @@
 # For a description of the syntax of this configuration file,
 # see Documentation/kbuild/config-language.txt.
 #
+
+source arch/config.in
+
 mainmenu_name "Linux/SuperH Kernel Configuration"
 
 define_bool CONFIG_SUPERH y
Index: 5.54/arch/arm/config.in
--- 5.54/arch/arm/config.in Fri, 29 Jun 2001 11:31:04 +1000 kaos (linux-2.4/x/c/32_config.in 1.3.1.2.1.1 644)
+++ 5.54(w)/arch/arm/config.in Sat, 30 Jun 2001 21:28:43 +1000 kaos (linux-2.4/x/c/32_config.in 1.3.1.2.1.1 644)
@@ -2,6 +2,9 @@
 # For a description of the syntax of this configuration file,
 # see Documentation/kbuild/config-language.txt.
 #
+
+source arch/config.in
+
 mainmenu_name "Linux Kernel Configuration"
 
 define_bool CONFIG_ARM y
Index: 5.54/arch/sparc64/config.in
--- 5.54/arch/sparc64/config.in Fri, 29 Jun 2001 11:31:04 +1000 kaos (linux-2.4/z/c/48_config.in 1.11.1.1 644)
+++ 5.54(w)/arch/sparc64/config.in Sat, 30 Jun 2001 21:29:37 +1000 kaos (linux-2.4/z/c/48_config.in 1.11.1.1 644)
@@ -2,6 +2,9 @@
 # For a description of the syntax of this configuration file,
 # see the Configure script.
 #
+
+source arch/config.in
+
 mainmenu_name "Linux/UltraSPARC Kernel Configuration"
 
 mainmenu_option next_comment
Index: 5.54/arch/m68k/config.in
--- 5.54/arch/m68k/config.in Wed, 06 Jun 2001 11:47:52 +1000 kaos (linux-2.4/E/c/5_config.in 1.1.1.4 644)
+++ 5.54(w)/arch/m68k/config.in Sat, 30 Jun 2001 21:40:20 +1000 kaos (linux-2.4/E/c/5_config.in 1.1.1.4 644)
@@ -3,6 +3,9 @@
 # see Documentation/kbuild/config-language.txt.
 #
 
+source arch/config.in
+
+define_bool CONFIG_ARCH_M68K y
 define_bool CONFIG_UID16 y
 define_bool CONFIG_RWSEM_GENERIC_SPINLOCK y
 define_bool CONFIG_RWSEM_XCHGADD_ALGORITHM n
Index: 5.54/arch/ppc/config.in
--- 5.54/arch/ppc/config.in Fri, 29 Jun 2001 11:31:04 +1000 kaos (linux-2.4/H/c/11_config.in 1.2.1.1.2.4.1.1 644)
+++ 5.54(w)/arch/ppc/config.in Sat, 30 Jun 2001 21:29:25 +1000 kaos (linux-2.4/H/c/11_config.in 1.2.1.1.2.4.1.1 644)
@@ -3,6 +3,9 @@
 # For a description of the syntax of this configuration file,
 # see Documentation/kbuild/config-language.txt.
 #
+
+source arch/config.in
+
 define_bool CONFIG_UID16 n
 define_bool CONFIG_RWSEM_GENERIC_SPINLOCK n
 define_bool CONFIG_RWSEM_XCHGADD_ALGORITHM y
Index: 5.54/arch/mips/config.in
--- 5.54/arch/mips/config.in Wed, 20 Jun 2001 13:07:10 +1000 kaos (linux-2.4/M/c/48_config.in 1.1.1.1.1.2 644)
+++ 5.54(w)/arch/mips/config.in Sat, 30 Jun 2001 21:29:13 +1000 kaos (linux-2.4/M/c/48_config.in 1.1.1.1.1.2 644)
@@ -2,6 +2,9 @@
 # For a description of the syntax of this configuration file,
 # see Documentation/kbuild/config-language.txt.
 #
+
+source arch/config.in
+
 define_bool CONFIG_MIPS y
 define_bool CONFIG_SMP n
 
Index: 5.54/arch/sparc/config.in
--- 5.54/arch/sparc/config.in Fri, 29 Jun 2001 11:31:04 +1000 kaos (linux-2.4/P/c/8_config.in 1.3.1.2.1.1 644)
+++ 5.54(w)/arch/sparc/config.in Sat, 30 Jun 2001 21:29:35 +1000 kaos (linux-2.4/P/c/8_config.in 1.3.1.2.1.1 644)
@@ -2,6 +2,9 @@
 # For a description of the syntax of this configuration file,
 # see Documentation/kbuild/config-language.txt.
 #
+
+source arch/config.in
+
 mainmenu_name "Linux/SPARC Kernel Configuration"
 
 define_bool CONFIG_UID16 y
Index: 5.54/arch/alpha/config.in
--- 5.54/arch/alpha/config.in Fri, 29 Jun 2001 11:31:04 +1000 kaos (linux-2.4/R/c/33_config.in 1.1.1.1.1.5 644)
+++ 5.54(w)/arch/alpha/config.in Sat, 30 Jun 2001 21:27:01 +1000 kaos (linux-2.4/R/c/33_config.in 1.1.1.1.1.5 644)
@@ -3,6 +3,8 @@
 # see Documentation/kbuild/config-language.txt.
 #
 
+source arch/config.in
+
 define_bool CONFIG_ALPHA y
 define_bool CONFIG_UID16 n
 define_bool CONFIG_RWSEM_GENERIC_SPINLOCK y
Index: 5.54/arch/i386/config.in
--- 5.54/arch/i386/config.in Fri, 29 Jun 2001 11:31:04 +1000 kaos (linux-2.4/T/c/36_config.in 1.1.2.1.3.1.1.9 644)
+++ 5.54(w)/arch/i386/config.in Sat, 30 Jun 2001 21:28:59 +1000 kaos (linux-2.4/T/c/36_config.in 1.1.2.1.3.1.1.9 644)
@@ -2,6 +2,9 @@
 # For a description of the syntax of this configuration file,
 # see Documentation/kbuild/config-language.txt.
 #
+
+source arch/config.in
+
 mainmenu_name "Linux Kernel Configuration"
 
 define_bool CONFIG_X86 y
Index: 5.54/arch/cris/config.in
--- 5.54/arch/cris/config.in Wed, 20 Jun 2001 13:07:10 +1000 kaos (linux-2.4/m/d/45_config.in 1.2.1.5 644)
+++ 5.54(w)/arch/cris/config.in Sat, 30 Jun 2001 21:40:14 +1000 kaos (linux-2.4/m/d/45_config.in 1.2.1.5 644)
@@ -2,8 +2,12 @@
 # For a description of the syntax of this configuration file,
 # see the Configure script.
 #
+
+source arch/config.in
+
 mainmenu_name "Linux/CRIS Kernel Configuration"
 
+define_bool CONFIG_ARCH_CRIS y
 define_bool CONFIG_UID16 y
 define_bool CONFIG_RWSEM_GENERIC_SPINLOCK y
 define_bool CONFIG_RWSEM_XCHGADD_ALGORITHM n
Index: 5.54/arch/s390x/config.in
--- 5.54/arch/s390x/config.in Sun, 22 Apr 2001 08:14:43 +1000 kaos (linux-2.4/q/d/3_config.in 1.3 644)
+++ 5.54(w)/arch/s390x/config.in Sat, 30 Jun 2001 21:27:53 +1000 kaos (linux-2.4/q/d/3_config.in 1.3 644)
@@ -3,6 +3,8 @@
 # see Documentation/kbuild/config-language.txt.
 #
 
+source arch/config.in
+
 define_bool CONFIG_ISA n
 define_bool CONFIG_EISA n
 define_bool CONFIG_MCA n
Index: 5.54/arch/um/config.in
--- 5.54/arch/um/config.in Sat, 16 Jun 2001 09:05:21 +1000 kaos (linux-2.4/U/d/26_config.in 1.4 644)
+++ 5.54(w)/arch/um/config.in Sat, 30 Jun 2001 21:29:42 +1000 kaos (linux-2.4/U/d/26_config.in 1.4 644)
@@ -1,5 +1,6 @@
-define_bool CONFIG_USERMODE y
+source arch/config.in
 
+define_bool CONFIG_USERMODE y
 mainmenu_name "Linux/Usermode Kernel Configuration"
 
 define_bool CONFIG_ISA y

Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Russell King]

On Sat, Jun 30, 2001 at 09:45:30PM +1000, Keith Owens wrote:
> CONFIG_bar can be undefined, not 'n'.  While that can cause problems,
> it is also valid config code.  If I interpret AC's cryptic comments
> correctly, there may be code which assumes that undefined variables are
> just that, undefined.  Setting all variables to 'n' initially by Adam's
> script will break such code.

Agreed.   The person who should know for sure how the configuration system
works is ESR.

> I still think this is the best approach, against 2.4.5-ac22.

One small concern - does it work properly with xconfig and menuconfig?
I seem to remember that they re-evaluate choices, and I have this feeling
that I've seen unselectable symbols caused by define_bool SYM n type stuff.

Note also that we in the ARM port currently have 43 such symbols in either
Linus' or my tree, and there are getting on for 90 such symbols in existence
throughout the ARM trees.  (There are around 90 registered ARM machine types
at the moment, each one has their own CONFIG symbol).

Your config.in file could get very large. ;)

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

linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Adam J. Richter]

	The Config.in files in linux-2.4.6-pre6 have at least 28 cases
where a dep_bool or dep_tristate of the following form:

	dep_bool CONFIG_SOMETHING $CONFIG_ARCH_somearch

	The problem with this is that, unlike most configuration variables,
the $CONFIG_ARCH_xxxx variables are often not set to "n" when they are
not selected (they are often just not defined, for example, when they
are archectures for a completely different CPU type).  When those variables
are not defined, that is essentially equivalent to passing "y" to dep_bool,
and the user is incorrectly asked about these facilities.

	I will put together patch to convert this to ugly but correct
"if then; ... ; fi" statements later today if nobody has any better
suggestions.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Keith Owens]

On Fri, 29 Jun 2001 07:10:51 -0700, 
"Adam J. Richter" <adam@yggdrasil.com> wrote:
>	The Config.in files in linux-2.4.6-pre6 have at least 28 cases
>where a dep_bool or dep_tristate of the following form:
>	dep_bool CONFIG_SOMETHING $CONFIG_ARCH_somearch
>	I will put together patch to convert this to ugly but correct
>"if then; ... ; fi" statements later today if nobody has any better
>suggestions.

Create arch/Config.in which contains

  define_bool CONFIG_ARCH_i386 n
  define_bool CONFIG_ARCH_ia64 n
  define_bool CONFIG_ARCH_sparc n

etc., then change each of the arch/xxx/Config.in files to
source arch/Config.in as their first line first.  Still ugly but the
mainline configs will be much more readable.  It also guarantees that
any future tests on $CONFIG_ARCH_somearch will work, even if the code
does not use if statements.

Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Russell King]

On Sat, Jun 30, 2001 at 12:21:09AM +1000, Keith Owens wrote:
> Create arch/Config.in which contains
> 
>   define_bool CONFIG_ARCH_i386 n
>   define_bool CONFIG_ARCH_ia64 n
>   define_bool CONFIG_ARCH_sparc n
> 
> etc., then change each of the arch/xxx/Config.in files to
> source arch/Config.in as their first line first.  Still ugly but the
> mainline configs will be much more readable.  It also guarantees that
> any future tests on $CONFIG_ARCH_somearch will work, even if the code
> does not use if statements.

I'd rather that we fixed dep_* so that undefined symbols were treated as
'n', just like the makefiles treat undefined symbols.

On ARM, we have a lot of CONFIG_ARCH_* variables (which yes, I know, should
be CONFIG_MACH_*, but its too late to change it now), and cluttering up the
place with lots of if ... then fi stuff is much less readable than the
dep_* stuff.

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

Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Keith Owens]

On Fri, 29 Jun 2001 15:30:36 +0100, 
Russell King <rmk@arm.linux.org.uk> wrote:
>On Sat, Jun 30, 2001 at 12:21:09AM +1000, Keith Owens wrote:
>> Create arch/Config.in which contains
>> 
>>   define_bool CONFIG_ARCH_i386 n
>>   define_bool CONFIG_ARCH_ia64 n
>>   define_bool CONFIG_ARCH_sparc n
>> 
>> etc., then change each of the arch/xxx/Config.in files to
>> source arch/Config.in as their first line first.
>
>I'd rather that we fixed dep_* so that undefined symbols were treated as
>'n', just like the makefiles treat undefined symbols.

make config and oldconfig are shell scripts.  They are limited to what
shells can do which includes "undefined variables are null", the
variable expansion is done before tristate and friends are invoked.
Of course, you could rewrite bash ...

Just put this down as one of the many "interesting" features of CML1,
put a band aid on it and move on to CML2.

Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Alan Cox]

> > mainline configs will be much more readable.  It also guarantees that
> > any future tests on $CONFIG_ARCH_somearch will work, even if the code
> > does not use if statements.
> 
> I'd rather that we fixed dep_* so that undefined symbols were treated as
> 'n', just like the makefiles treat undefined symbols.

That isnt a simple change. dep_tristate is used both to express 'need this'
and also 'conflicts with'. Those are ambiguous. You'd need to extend the
syntax say by adding  ${FOO:N} syntax 

Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Jeff Garzik]

"Adam J. Richter" wrote:
>         I will put together patch to convert this to ugly but correct
> "if then; ... ; fi" statements later today if nobody has any better
> suggestions.

Don't dirty up the Config.in.  Define CONFIG_ARCH_xxx in various arches
where needed.

Some, like CONFIG_X86 for example, definitely needs to be declared in
arch/$arch/config.in in some places.

-- 
Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |