Re: Linux 2.4.20-pre1

Re: Linux 2.4.20-pre1

[Andi Kleen]

Alan Cox <alan@redhat.com> 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

Re: Linux 2.4.20-pre1

[Alan Cox]

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.

64bit clean drivers was Re: Linux 2.4.20-pre1

[Andi Kleen]

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

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

[Alan Cox]

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

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

[Andi Kleen]

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

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

[Alan Cox]

> 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

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

[Andi Kleen]

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

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

[Alan Cox]

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

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

[Andi Kleen]

> 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

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

[Alan Cox]

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

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

[Jeff Garzik]

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

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

[Peter Samuelson]

[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, <mec@shout.net>
 # - Improve the exit message (Jeff Ronne).
+#
+# 7 Aug 2002, Peter Samuelson, <peter@cadcamlab.org>
+# - 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 <kaos@ocs.com.au>
 # 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 <peter@cadcamlab.org>
+# 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 $#

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

[Kai Germaschewski]

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

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

[Peter Samuelson]

[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

[patch] config language dep_* enhancements

[Peter Samuelson]

  [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, <mec@shout.net>
 # - Improve the exit message (Jeff Ronne).
+#
+# 8 Aug 2002, Peter Samuelson <peter@cadcamlab.org>
+# 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 <kaos@ocs.com.au>
 # 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 <peter@cadcamlab.org>
+# 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"
 	}
 

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

[Greg Banks]

G'day,

I like the basic idea here, and I'm pleased that someone has the courage to
tackle some of the brokenness of the kconfig language (if only because it
will provide me with a precedent when I try to submit some of my patches ;-).

I was a bit worried when I first saw the patch (after all, kconfig is held
together with spit and string) but on careful reading it's mostly doing the
right thing.  Mostly.

Peter Samuelson wrote:
> 
>   [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.  

You're willing to potentially perturb 2.4?

> I still haven't touched xconfig, because frankly it scares
> me.  The tkparse.c vs Peter match is well underway, stay tuned..

Good luck, it scares me too.

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

The last statement is inconsistent with the shell code and the explanations of 
the dep_* statements, which sensibly preserve the current semantics where
an undefined symbol has a distinct fourth value which is not y, m or n.

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.


> +    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".

Perhaps "negates" isn't quite the right word in four-state logic.

> --- 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
> @@ -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) ;;

Don't you want to check at this point that arg starts with CONFIG_?
Also, how about quoting \$$arg  ?

> +         esac
> +         case "$neg$arg" in
> +           m) cur_dep=m ;;
> +           n|Ny|Nm) cur_dep=n; return ;;
> +         esac

When CONFIG_FOO is undefined, !CONFIG_FOO and CONFIG_FOO are both ignored,
which is not consistent with the mention of "!" in the explanations for the
dep_* statements.  Perhaps you need to more carefully define the semantics
of the ! prefix.

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.

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

[Andreas Schwab]

Greg Banks <gnb@alphalink.com.au> writes:

|> > --- 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
|> > @@ -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) ;;
|> 
|> Don't you want to check at this point that arg starts with CONFIG_?
|> Also, how about quoting \$$arg  ?

The Right Way to write that is like this, assuming that $arg has already
been verified to be a valid identifier:

          eval arg=\$$arg

No need for further quoting.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Greg Banks]

Andreas Schwab wrote:
> 
> |> > +         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  ?
> 
> The Right Way to write that is like this, assuming that $arg has already
> been verified to be a valid identifier:

Yes, assuming that happens...

>           eval arg=\$$arg
> 
> No need for further quoting.

you're right.

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.

Re: [patch] config language dep_* enhancements

[Peter Samuelson]

[Greg Banks]
> I like the basic idea here, and I'm pleased that someone has the
> courage to tackle some of the brokenness of the kconfig language (if
> only because it will provide me with a precedent when I try to
> submit some of my patches ;-).

Thanks for the feedback. (:

> > This applies to 2.4.20pre and (except changelog bits) to 2.5.30 with
> > offsets.  
> 
> 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.  Obviously xconfig would need to be dealt with
in sync with the others, which I'm not doing during the prototyping /
idea-mongering stage.

> The last statement is inconsistent with the shell code and the
> explanations of the dep_* statements, which sensibly preserve the
> current semantics where an undefined symbol has a distinct fourth
> value which is not y, m or n.
> 
> 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.

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".  Can you provide a rationale for why the current
behavior is desirable?  It seems to me that it only encourages buggy
Config.in code (since "" == "n" in other contexts like the #defines),
and I don't see any benefits other than that it's the status quo.

[Not to demean the status quo - in 2.4 it is probably appropriate.]

> > +    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".
> 
> Perhaps "negates" isn't quite the right word in four-state logic.

I wasn't sure what else to call it.  Besides, as explained above, it's
intended (rightly or wrongly) to be 3-state logic, where two states
represent a form of "true". (:

Perhaps "the /dep/ may have a prefix "!", which transforms the
/tristate/ as follows: ..."  This is particularly appropriate in light
of Roman's argument (which I buy) in favor of "!m" == "m".

> > +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) ;;
> 
> 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.  I'm not really trying
to produce a config.in 'lint' - leave that to the static parsers like
gcml2, xconfig and mconfig.

Peter

Re: [patch] config language dep_* enhancements

[Greg Banks]

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.

Re: [patch] config language dep_* enhancements

[Kai Germaschewski]

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

Re: [patch] config language dep_* enhancements

[Roman Zippel]

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

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

[Tom Rini]

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/

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

[Roman Zippel]

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

Re: [patch] config language dep_* enhancements

[Tom Rini]

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/

Re: [patch] config language dep_* enhancements

[Roman Zippel]

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

Re: [patch] config language dep_* enhancements

[Tom Rini]

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/

Re: [patch] config language dep_* enhancements

[Roman Zippel]

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

Re: [patch] config language dep_* enhancements

[Tom Rini]

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/

Re: [patch] config language dep_* enhancements

[Greg Banks]

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.

Re: [patch] config language dep_* enhancements

[Peter Samuelson]

[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

Re: [patch] config language dep_* enhancements

[Roman Zippel]

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

Re: [patch] config language dep_* enhancements

[Greg Banks]

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.

Re: [patch] config language dep_* enhancements

[Roman Zippel]

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

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

[Greg Banks]

Roman Zippel wrote:
> 
> On Tue, 13 Aug 2002, Greg Banks wrote:
> 
> > 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.

http://marc.theaimsgroup.com/?l=linux-kernel&m=101387128818052&w=2

> CML2 has more problems than this. 

Agreed.  I was just pointing out that one of the many objections to CML2
would also apply to any new language which wasn't provably mappable from
CML1.

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

Nor was it wise to use Python, and less so to insist on a cutting edge
version of Python, nor to throw away all the user interfaces, etc etc.
And don't even get me started on pickling and freezing.  Its very easy
to be wise in hindsight; let's use that wisdom to do better this time.

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.

Re: [patch] config language dep_* enhancements

[Peter Samuelson]

[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

Re: [patch] config language dep_* enhancements

[Greg Banks]

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.

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

[Greg Banks]

[-- Attachment #1: Type: text/plain, Size: 434 bytes --]

Peter Samuelson wrote:
> 
> [...] 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".

Ok, here it is.  

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.

[-- Attachment #2: forward-deps2.txt.gz --]
[-- Type: application/x-gzip, Size: 3259 bytes --]

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

[Peter Samuelson]

[Greg Banks]
> Ok, here it is.  

Thanks again.  It will take some time to double-check what I termed
the "false positives", but now you've reduced the "interesting cases"
down to 30 symbols.

(BTW, the format is great - I can use 'M-x compile' and 'M-x
next-error' and Emacs pulls up files and lines for me.)

Here are the problem cases - things known to break with my proposed
'n'=='' - and my proposed solutions.  I'll see if I can roll a patch
later today:


CONFIG_SCSI should be defined earlier, like in the "Block Devices"
menu.  Then again, 'sg' is not a block device so this isn't strictly
correct.  Perhaps a "kernel subsystems" submenu under "general setup",
or even as a toplevel menu.

CONFIG_I2C and CONFIG_USB are also widely used outside their own
subtrees.  They should probably go in with the "kernel subsystems"
menu along with CONFIG_SCSI.

CONFIG_PROC_FS is needed by ISDN hysdn.  That's actually in my opinion
more of a "general kernel facility" than a filesystem.  Eh?

Then again it could be said that requiring CONFIG_PROC_FS is actually
a design bug in hysdn - does the driver *really* need CONFIG_PROC_FS?
Everything else in the kernel seems to cope without it.  Granted,
non-/proc kernels are not widely tested....  Kai?

CONFIG_ISDN_CAPI - interestingly, CONFIG_HYSDN_CAPI, which is under
the menu "Old ISDN4Linux (obsolete)" seems to require CAPI 2.0.  I
suppose the CAPI stuff should come first in drivers/isdn/Config.in.
Kai?

CONFIG_SOUND_ACI_MIXER - the miroSOUND radio driver wants something
from OSS sound.  Really I think sound/Config.in "Sound Card Support"
should be moved to a sub-menu of drivers/media/Config.in "Multimedia
Devices".

CONFIG_INPUT - arch/{alpha,mips,mips64}/config.in are broken.  There's
a comment in other arch/*/config.in files to the effect that
drivers/input/Config.in must come before drivers/usb/input/Config.in.
These 3 explicitly do the opposite.

CONFIG_SOUND_GAMEPORT - defined in drivers/input/gameport/, used only
in sound/oss/.  I'm not sure what's going on here - why a separate
define (there is also CONFIG_GAMEPORT), and why do some sound cards
require its presence?  Also I'm a bit suspicious of the logic in
drivers/input/gameport/ - it's either buggy, or way too clever.

This one is just confusing.  Not sure what to recommend.  I'll
probably have to stare at the Makefiles and the C for awhile to see
what's actually going on.

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

[Kai Germaschewski]

On Tue, 13 Aug 2002, Peter Samuelson wrote:

> CONFIG_PROC_FS is needed by ISDN hysdn.  That's actually in my opinion
> more of a "general kernel facility" than a filesystem.  Eh?

Well, the use in hysdn can (and should) die, possibly by adding an
#ifndef CONFIG_PROC_FS
#error This driver won't work without procfs
#endif
until fixed properly.

> Then again it could be said that requiring CONFIG_PROC_FS is actually
> a design bug in hysdn - does the driver *really* need CONFIG_PROC_FS?
> Everything else in the kernel seems to cope without it.  Granted,
> non-/proc kernels are not widely tested....  Kai?

I don't know, I suspect it needs it for something like firmware loading or 
so. But since that's obviously an abuse of /proc, it's okay to have it 
break IMO.

> CONFIG_ISDN_CAPI - interestingly, CONFIG_HYSDN_CAPI, which is under
> the menu "Old ISDN4Linux (obsolete)" seems to require CAPI 2.0.  I
> suppose the CAPI stuff should come first in drivers/isdn/Config.in.
> Kai?

Yes. I'll look into that and fix it properly - I think just exchanging 
probably gives the same kind of problem for CONFIG_ISDN ;(

--Kai

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

[Greg Banks]

Peter Samuelson wrote:
> 
> (BTW, the format is great - I can use 'M-x compile' and 'M-x
> next-error' and Emacs pulls up files and lines for me.)

This is not a coincidence.

> CONFIG_SCSI should be defined earlier, like in the "Block Devices"
> menu.  Then again, 'sg' is not a block device so this isn't strictly
> correct.  Perhaps a "kernel subsystems" submenu under "general setup",
> or even as a toplevel menu.

Sounds like a good idea.  You could put CONFIG_SERIAL and CONFIG_PCMCIA
in there too.

> CONFIG_INPUT - arch/{alpha,mips,mips64}/config.in are broken.  There's
> a comment in other arch/*/config.in files to the effect that
> drivers/input/Config.in must come before drivers/usb/input/Config.in.
> These 3 explicitly do the opposite.

There are many broken things about the arch toplevel config.ins, mostly
due to them starting life as copy-n-paste jobs from arch/i386/config.in
and then slowly diverging.  A brief sampling from my bugs list...

*   CONFIG_KERNEL_ELF
    	Defined in arch/ppc/config.in as "define_bool CONFIG_KERNEL_ELF y".
	Specified in a large number of ppc defconfigs.
	Not used anywhere in the source.
	Appears to be an obsolete artifact.
	
    CONFIG_ELF_KERNEL
    	Defined in arch/mips/config.in as "define_bool CONFIG_ELF_KERNEL y".
	Specified in a large number of mips defconfigs.
	Not used anywhere in the source.
	Appears to be an obsolete artifact.

*   arch/ia64/config.in has this:

	if [ "$CONFIG_DEVFS_FS" = "y" ]; then
	  bool '    Enable DEVFS Debug Code' CONFIG_DEVFS_DEBUG n
	fi

    but why!?!? Not only does this have a bogus third argument as
    if it were dep_bool, but it defines a symbol already defined
    over in fs/Config.in, which is *included* from this config.in.

*   Most architectures have two global menus "General setup", one from
    their own arch/foo/config.in, one from init/Config.in.

*   One of these two correctly describes the device(s) it supports:

    arch/m68k/config.in:      dep_tristate 'A2091 WD33C93A support' CONFIG_A2091_SCSI $CONFIG_SCSI
    drivers/scsi/Config.in:   dep_tristate 'A2091/A590 WD33C93A support' CONFIG_A2091_SCSI $CONFIG_SCSI

*   What's the story with CONFIG_ALPHA_EV56?  It's defined as a symbol
    three times in arch/alpha/config.in with different banners:
    
            bool 'EV56 CPU (speed >= 333MHz)?' CONFIG_ALPHA_EV56
    bool 'EV56 CPU (speed >= 366MHz)?' CONFIG_ALPHA_EV56
    bool 'EV56 CPU (speed >= 400MHz)?' CONFIG_ALPHA_EV56

*   WTF?!?  arch/cris/drivers/bluetooth/Makefile has an install: target
    which actually hacks Config.in and Makefile in other directories!?!?!
    
*   There's a fair bit of confusion between the architectures about
    CONFIG_BINFMT_ELF{,32}...
    
    ARCH    C_B_ELF 	C_B_ELF32
    ----    ------- 	---------
    alpha   	1
    arm     	1
    cris    	1
    i386    	1
    ia64    	1
    m68k    	1
    mips64  	2   	    4
    mips    	3
    parisc  	1
    ppc64   	2   	    5
    ppc     	3
    s390    	1
    s390x   	1   	    6
    sh	    	1
    sparc64 	2   	    5
    sparc   	1
    x86_64  	1

    
    1='Kernel support for ELF binaries'
    2='Kernel support for 64-bit ELF binaries'
    3=define_bool
    4=define_bool,unset
    5='Kernel support for 32-bit ELF binaries'
    6='Kernel support for 31 bit ELF binaries'

    Note that the interpretation of CONFIG_BINFMT_ELF appears to be
    "support for largest-ELF" but some 64 bit platforms present this
    to the user as explicitly "64-bit" while other 64 bit platforms
    don't seem to care.  The 32-bit platforms just pretend there's
    no such thing as 64-bits.


> CONFIG_SOUND_GAMEPORT - defined in drivers/input/gameport/, used only
> in sound/oss/.  I'm not sure what's going on here

I couldn't figure out CONFIG_SOUND_GAMEPORT or CONFIG_INPUT_GAMEPORT either.


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.

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

[Peter Samuelson]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]


[Greg Banks]
  [I wrote]
> > (BTW, the format is great - I can use 'M-x compile' and 'M-x
> > next-error' and Emacs pulls up files and lines for me.)
> 
> This is not a coincidence.

Indeed not - if you hadn't already used that format I would have
munged it.  Grew up on gcc, so this is my favorite error message
format.  Yours too, I guess. (:

> > CONFIG_SCSI should be defined earlier, like in the "Block Devices"
> > menu.  Then again, 'sg' is not a block device so this isn't strictly
> > correct.  Perhaps a "kernel subsystems" submenu under "general setup",
> > or even as a toplevel menu.
> 
> Sounds like a good idea.  You could put CONFIG_SERIAL and CONFIG_PCMCIA
> in there too.

CONFIG_SERIAL and CONFIG_PCMCIA didn't generate any noise, though.
Minimum necessary change and all that.  It's easy enough to add later,
if desired.

Here's a start.  It looks a little hacky but it does fix real issues.
I decided to combine "general setup", "module config" and "major
subsystems" - the latter needs to come after modules but really
belongs with general setup.  Eh?

I think the first patch belongs on trivial@rustcorp - what's the
protocol there, just an email cc?  Attach or inline?  etc.

Peter

[-- Attachment #2: 1.diff --]
[-- Type: text/plain, Size: 1663 bytes --]

diff -urNXxpk 2.5.31/arch/alpha/config.in 2.5.31-1/arch/alpha/config.in
--- 2.5.31/arch/alpha/config.in	2002-08-11 15:08:07.000000000 -0500
+++ 2.5.31-1/arch/alpha/config.in	2002-08-13 20:49:18.000000000 -0500
@@ -340,6 +340,10 @@
 fi
 endmenu
 
+#
+# input before char - char/joystick depends on it. As does USB.
+#
+source drivers/input/Config.in
 source drivers/char/Config.in
 
 #source drivers/misc/Config.in
@@ -375,7 +379,6 @@
 endmenu
 
 source drivers/usb/Config.in
-source drivers/input/Config.in
 
 source net/bluetooth/Config.in
 
diff -urNXxpk 2.5.31/arch/mips/config.in 2.5.31-1/arch/mips/config.in
--- 2.5.31/arch/mips/config.in	2002-08-11 15:08:07.000000000 -0500
+++ 2.5.31-1/arch/mips/config.in	2002-08-13 20:48:35.000000000 -0500
@@ -400,6 +400,10 @@
 fi
 endmenu
 
+#
+# input before char - char/joystick depends on it. As does USB.
+#
+source drivers/input/Config.in
 source drivers/char/Config.in
 
 source drivers/media/Config.in
@@ -485,7 +489,6 @@
 fi
 
 source drivers/usb/Config.in
-source drivers/input/Config.in
 
 mainmenu_option next_comment
 comment 'Kernel hacking'
diff -urNXxpk 2.5.31/arch/mips64/config.in 2.5.31-1/arch/mips64/config.in
--- 2.5.31/arch/mips64/config.in	2002-08-11 15:08:07.000000000 -0500
+++ 2.5.31-1/arch/mips64/config.in	2002-08-13 20:49:00.000000000 -0500
@@ -191,6 +191,10 @@
 fi
 endmenu
 
+#
+# input before char - char/joystick depends on it. As does USB.
+#
+source drivers/input/Config.in
 source drivers/char/Config.in
 
 #source drivers/misc/Config.in
@@ -232,7 +236,6 @@
 fi
 
 source drivers/usb/Config.in
-source drivers/input/Config.in
 
 mainmenu_option next_comment
 comment 'Kernel hacking'

[-- Attachment #3: 2.diff --]
[-- Type: text/plain, Size: 14148 bytes --]

diff -urNXxpk 2.5.31-1/arch/alpha/config.in 2.5.31-2/arch/alpha/config.in
--- 2.5.31-1/arch/alpha/config.in	2002-08-13 20:49:18.000000000 -0500
+++ 2.5.31-2/arch/alpha/config.in	2002-08-13 22:07:23.000000000 -0500
@@ -299,15 +299,12 @@
 fi
 endmenu
 
-mainmenu_option next_comment
-comment 'SCSI support'
-
-tristate 'SCSI support' CONFIG_SCSI
-
 if [ "$CONFIG_SCSI" != "n" ]; then
+  mainmenu_option next_comment
+  comment 'SCSI support'
   source drivers/scsi/Config.in
+  endmenu
 fi
-endmenu
 
 if [ "$CONFIG_PCI" = "y" ]; then
   source drivers/message/fusion/Config.in
diff -urNXxpk 2.5.31-1/arch/arm/config.in 2.5.31-2/arch/arm/config.in
--- 2.5.31-1/arch/arm/config.in	2002-08-11 15:08:07.000000000 -0500
+++ 2.5.31-2/arch/arm/config.in	2002-08-13 22:07:42.000000000 -0500
@@ -559,15 +559,12 @@
 fi
 endmenu
 
-mainmenu_option next_comment
-comment 'SCSI support'
-
-tristate 'SCSI support' CONFIG_SCSI
-
 if [ "$CONFIG_SCSI" != "n" ]; then
+   mainmenu_option next_comment
+   comment 'SCSI support'
    source drivers/scsi/Config.in
+   endmenu
 fi
-endmenu
 
 if [ "$CONFIG_ARCH_CLPS711X" = "y" ]; then
    source drivers/ssi/Config.in
diff -urNXxpk 2.5.31-1/arch/cris/config.in 2.5.31-2/arch/cris/config.in
--- 2.5.31-1/arch/cris/config.in	2002-07-27 04:14:32.000000000 -0500
+++ 2.5.31-2/arch/cris/config.in	2002-08-13 22:08:01.000000000 -0500
@@ -153,15 +153,12 @@
 fi
 endmenu
 
-mainmenu_option next_comment
-comment 'SCSI support'
-
-tristate 'SCSI support' CONFIG_SCSI
-
 if [ "$CONFIG_SCSI" != "n" ]; then
+  mainmenu_option next_comment
+  comment 'SCSI support'
   source drivers/scsi/Config.in
+  endmenu
 fi
-endmenu
 
 source drivers/ieee1394/Config.in
 
diff -urNXxpk 2.5.31-1/arch/i386/config.in 2.5.31-2/arch/i386/config.in
--- 2.5.31-1/arch/i386/config.in	2002-08-11 15:08:07.000000000 -0500
+++ 2.5.31-2/arch/i386/config.in	2002-08-13 22:05:49.000000000 -0500
@@ -311,15 +311,12 @@
 fi
 endmenu
 
-mainmenu_option next_comment
-comment 'SCSI device support'
-
-tristate 'SCSI device support' CONFIG_SCSI
-
 if [ "$CONFIG_SCSI" != "n" ]; then
+   mainmenu_option next_comment
+   comment 'SCSI device support'
    source drivers/scsi/Config.in
+   endmenu
 fi
-endmenu
 
 mainmenu_option next_comment
 comment 'Old non-SCSI/ATAPI CD-ROM drives'
diff -urNXxpk 2.5.31-1/arch/ia64/config.in 2.5.31-2/arch/ia64/config.in
--- 2.5.31-1/arch/ia64/config.in	2002-08-08 22:43:27.000000000 -0500
+++ 2.5.31-2/arch/ia64/config.in	2002-08-13 22:08:38.000000000 -0500
@@ -157,15 +157,12 @@
 endmenu
 fi # !HP_SIM
 
-mainmenu_option next_comment
-comment 'SCSI support'
-
-tristate 'SCSI support' CONFIG_SCSI
-
 if [ "$CONFIG_SCSI" != "n" ]; then
+  mainmenu_option next_comment
+  comment 'SCSI support'
   source drivers/scsi/Config.in
+  endmenu
 fi
-endmenu
 
 if [ "$CONFIG_IA64_HP_SIM" = "n" ]; then
 
diff -urNXxpk 2.5.31-1/arch/m68k/config.in 2.5.31-2/arch/m68k/config.in
--- 2.5.31-1/arch/m68k/config.in	2002-08-11 15:08:07.000000000 -0500
+++ 2.5.31-2/arch/m68k/config.in	2002-08-13 22:09:34.000000000 -0500
@@ -172,12 +172,9 @@
 fi
 endmenu
 
-mainmenu_option next_comment
-comment 'SCSI device support'
-
-tristate 'SCSI device support' CONFIG_SCSI
-
 if [ "$CONFIG_SCSI" != "n" ]; then
+   mainmenu_option next_comment
+   comment 'SCSI device support'
 
    comment 'SCSI support type (disk, tape, CD-ROM)'
 
@@ -266,9 +263,8 @@
    fi
 
    endmenu
-
+   endmenu
 fi
-endmenu
 
 if [ "$CONFIG_NET" = "y" ]; then
 
diff -urNXxpk 2.5.31-1/arch/mips/config.in 2.5.31-2/arch/mips/config.in
--- 2.5.31-1/arch/mips/config.in	2002-08-13 20:48:35.000000000 -0500
+++ 2.5.31-2/arch/mips/config.in	2002-08-13 22:09:54.000000000 -0500
@@ -356,15 +356,13 @@
    endmenu
 fi
 
-mainmenu_option next_comment
-comment 'SCSI support'
-
-tristate 'SCSI support' CONFIG_SCSI
 
 if [ "$CONFIG_SCSI" != "n" ]; then
+   mainmenu_option next_comment
+   comment 'SCSI support'
    source drivers/scsi/Config.in
+   endmenu
 fi
-endmenu
 
 if [ "$CONFIG_DECSTATION" != "y" -a \
      "$CONFIG_SGI_IP22" != "y" ]; then
diff -urNXxpk 2.5.31-1/arch/mips64/config.in 2.5.31-2/arch/mips64/config.in
--- 2.5.31-1/arch/mips64/config.in	2002-08-13 20:49:00.000000000 -0500
+++ 2.5.31-2/arch/mips64/config.in	2002-08-13 22:10:16.000000000 -0500
@@ -150,15 +150,12 @@
 fi
 endmenu
 
-mainmenu_option next_comment
-comment 'SCSI support'
-
-tristate 'SCSI support' CONFIG_SCSI
-
 if [ "$CONFIG_SCSI" != "n" ]; then
+   mainmenu_option next_comment
+   comment 'SCSI support'
    source drivers/scsi/Config.in
+   endmenu
 fi
-endmenu
 
 #source drivers/message/i2o/Config.in
 
diff -urNXxpk 2.5.31-1/arch/parisc/config.in 2.5.31-2/arch/parisc/config.in
--- 2.5.31-1/arch/parisc/config.in	2002-08-11 15:08:07.000000000 -0500
+++ 2.5.31-2/arch/parisc/config.in	2002-08-13 22:13:42.000000000 -0500
@@ -103,12 +103,10 @@
   source net/Config.in
 fi
 
-mainmenu_option next_comment
-comment 'SCSI support'
-
-tristate 'SCSI support' CONFIG_SCSI
-
 if [ "$CONFIG_SCSI" != "n" ]; then
+  mainmenu_option next_comment
+  comment 'SCSI support'
+
   comment 'SCSI support type (disk, tape, CDrom)'
 
   dep_tristate 'SCSI disk support' CONFIG_BLK_DEV_SD $CONFIG_SCSI
@@ -145,8 +143,8 @@
     bool '  use normal IO' CONFIG_SCSI_NCR53C8XX_IOMAPPED
   fi
   endmenu
+  endmenu
 fi
-endmenu
 
 if [ "$CONFIG_NET" = "y" ]; then
   mainmenu_option next_comment
diff -urNXxpk 2.5.31-1/arch/ppc/config.in 2.5.31-2/arch/ppc/config.in
--- 2.5.31-1/arch/ppc/config.in	2002-08-11 15:08:07.000000000 -0500
+++ 2.5.31-2/arch/ppc/config.in	2002-08-13 22:14:09.000000000 -0500
@@ -434,13 +434,12 @@
 fi
 endmenu
 
-mainmenu_option next_comment
-comment 'SCSI support'
-tristate 'SCSI support' CONFIG_SCSI
 if [ "$CONFIG_SCSI" != "n" ]; then
+   mainmenu_option next_comment
+   comment 'SCSI support'
    source drivers/scsi/Config.in
+   endmenu
 fi
-endmenu
 
 source drivers/message/fusion/Config.in
 
diff -urNXxpk 2.5.31-1/arch/ppc64/config.in 2.5.31-2/arch/ppc64/config.in
--- 2.5.31-1/arch/ppc64/config.in	2002-07-27 04:14:32.000000000 -0500
+++ 2.5.31-2/arch/ppc64/config.in	2002-08-13 22:14:24.000000000 -0500
@@ -103,13 +103,12 @@
 fi
 endmenu
 
-mainmenu_option next_comment
-comment 'SCSI support'
-tristate 'SCSI support' CONFIG_SCSI
 if [ "$CONFIG_SCSI" != "n" ]; then
+   mainmenu_option next_comment
+   comment 'SCSI support'
    source drivers/scsi/Config.in
+   endmenu
 fi
-endmenu
 
 source drivers/message/fusion/Config.in
 
diff -urNXxpk 2.5.31-1/arch/s390/config.in 2.5.31-2/arch/s390/config.in
--- 2.5.31-1/arch/s390/config.in	2002-07-27 04:14:33.000000000 -0500
+++ 2.5.31-2/arch/s390/config.in	2002-08-13 22:11:47.000000000 -0500
@@ -47,15 +47,13 @@
 bool 'VM shared kernel support' CONFIG_SHARED_KERNEL
 endmenu
 
-mainmenu_option next_comment
-comment 'SCSI support'
-
-tristate 'SCSI support' CONFIG_SCSI
 
 if [ "$CONFIG_SCSI" != "n" ]; then
+   mainmenu_option next_comment
+   comment 'SCSI support'
    source drivers/scsi/Config.in
+   endmenu
 fi
-endmenu
 
 source drivers/s390/Config.in
 
diff -urNXxpk 2.5.31-1/arch/s390x/config.in 2.5.31-2/arch/s390x/config.in
--- 2.5.31-1/arch/s390x/config.in	2002-07-27 04:14:33.000000000 -0500
+++ 2.5.31-2/arch/s390x/config.in	2002-08-13 22:11:48.000000000 -0500
@@ -50,15 +50,13 @@
 bool 'VM shared kernel support' CONFIG_SHARED_KERNEL
 endmenu
 
-mainmenu_option next_comment
-comment 'SCSI support'
-
-tristate 'SCSI support' CONFIG_SCSI
 
 if [ "$CONFIG_SCSI" != "n" ]; then
+   mainmenu_option next_comment
+   comment 'SCSI support'
    source drivers/scsi/Config.in
+   endmenu
 fi
-endmenu
 
 source drivers/s390/Config.in
 
diff -urNXxpk 2.5.31-1/arch/sh/config.in 2.5.31-2/arch/sh/config.in
--- 2.5.31-1/arch/sh/config.in	2002-08-11 15:08:07.000000000 -0500
+++ 2.5.31-2/arch/sh/config.in	2002-08-13 22:11:50.000000000 -0500
@@ -223,15 +223,13 @@
 fi
 endmenu
 
-mainmenu_option next_comment
-comment 'SCSI support'
-
-tristate 'SCSI support' CONFIG_SCSI
 
 if [ "$CONFIG_SCSI" != "n" ]; then
+   mainmenu_option next_comment
+   comment 'SCSI support'
    source drivers/scsi/Config.in
+   endmenu
 fi
-endmenu
 
 source drivers/ieee1394/Config.in
 
diff -urNXxpk 2.5.31-1/arch/sparc/config.in 2.5.31-2/arch/sparc/config.in
--- 2.5.31-1/arch/sparc/config.in	2002-08-11 15:08:07.000000000 -0500
+++ 2.5.31-2/arch/sparc/config.in	2002-08-13 22:14:51.000000000 -0500
@@ -112,12 +112,10 @@
 
 source drivers/isdn/Config.in
 
-mainmenu_option next_comment
-comment 'SCSI support'
-
-tristate 'SCSI support' CONFIG_SCSI
-
 if [ "$CONFIG_SCSI" != "n" ]; then
+   mainmenu_option next_comment
+   comment 'SCSI support'
+
    comment 'SCSI support type (disk, tape, CDrom)'
 
    dep_tristate '  SCSI disk support' CONFIG_BLK_DEV_SD $CONFIG_SCSI
@@ -152,8 +150,8 @@
    dep_tristate 'Sparc ESP Scsi Driver' CONFIG_SCSI_SUNESP $CONFIG_SCSI
    dep_tristate 'PTI Qlogic,ISP Driver' CONFIG_SCSI_QLOGICPTI $CONFIG_SCSI
    endmenu
+   endmenu
 fi
-endmenu
 
 source drivers/fc4/Config.in
 
diff -urNXxpk 2.5.31-1/arch/sparc64/config.in 2.5.31-2/arch/sparc64/config.in
--- 2.5.31-1/arch/sparc64/config.in	2002-08-11 15:08:09.000000000 -0500
+++ 2.5.31-2/arch/sparc64/config.in	2002-08-13 22:15:12.000000000 -0500
@@ -111,12 +111,10 @@
 fi
 endmenu
 
-mainmenu_option next_comment
-comment 'SCSI support'
-
-tristate 'SCSI support' CONFIG_SCSI
-
 if [ "$CONFIG_SCSI" != "n" ]; then
+   mainmenu_option next_comment
+   comment 'SCSI support'
+
    comment 'SCSI support type (disk, tape, CDrom)'
 
    dep_tristate '  SCSI disk support' CONFIG_BLK_DEV_SD $CONFIG_SCSI
@@ -195,8 +193,8 @@
    fi
 
    endmenu
+   endmenu
 fi
-endmenu
 
 source drivers/fc4/Config.in
 
diff -urNXxpk 2.5.31-1/arch/x86_64/config.in 2.5.31-2/arch/x86_64/config.in
--- 2.5.31-1/arch/x86_64/config.in	2002-07-27 04:14:33.000000000 -0500
+++ 2.5.31-2/arch/x86_64/config.in	2002-08-13 22:11:44.000000000 -0500
@@ -137,15 +137,13 @@
 fi
 endmenu
 
-mainmenu_option next_comment
-comment 'SCSI support'
-
-tristate 'SCSI support' CONFIG_SCSI
 
 if [ "$CONFIG_SCSI" != "n" ]; then
+   mainmenu_option next_comment
+   comment 'SCSI support'
    source drivers/scsi/Config.in
+   endmenu
 fi
-endmenu
 
 source drivers/message/fusion/Config.in
 
diff -urNXxpk 2.5.31-1/drivers/i2c/Config.in 2.5.31-2/drivers/i2c/Config.in
--- 2.5.31-1/drivers/i2c/Config.in	2002-07-19 09:14:57.000000000 -0500
+++ 2.5.31-2/drivers/i2c/Config.in	2002-08-13 22:18:35.000000000 -0500
@@ -1,14 +1,10 @@
 #
-# Character device configuration
+# I2C device configuration
 #
-mainmenu_option next_comment
-comment 'I2C support'
-
-tristate 'I2C support' CONFIG_I2C
-
 if [ "$CONFIG_I2C" != "n" ]; then
+   mainmenu_option next_comment
+   comment 'I2C support'
 
-   dep_tristate 'I2C bit-banging interfaces'  CONFIG_I2C_ALGOBIT $CONFIG_I2C
    if [ "$CONFIG_I2C_ALGOBIT" != "n" ]; then
       dep_tristate '  Philips style parallel port adapter' CONFIG_I2C_PHILIPSPAR $CONFIG_I2C_ALGOBIT $CONFIG_PARPORT
       dep_tristate '  ELV adapter' CONFIG_I2C_ELV $CONFIG_I2C_ALGOBIT
@@ -45,5 +41,5 @@
    dep_tristate 'I2C device interface' CONFIG_I2C_CHARDEV $CONFIG_I2C
    dep_tristate 'I2C /proc interface (required for hardware sensors)' CONFIG_I2C_PROC $CONFIG_I2C $CONFIG_SYSCTL
 
+   endmenu
 fi
-endmenu
diff -urNXxpk 2.5.31-1/drivers/input/Config.in 2.5.31-2/drivers/input/Config.in
--- 2.5.31-1/drivers/input/Config.in	2002-07-19 09:15:13.000000000 -0500
+++ 2.5.31-2/drivers/input/Config.in	2002-08-13 21:31:16.000000000 -0500
@@ -5,8 +5,6 @@
 mainmenu_option next_comment
 comment 'Input device support'
 
-tristate 'Input core support' CONFIG_INPUT
-
 comment 'Userland interfaces'
 dep_tristate '  Keyboard interface' CONFIG_INPUT_KEYBDEV $CONFIG_INPUT
 dep_tristate '  Mouse interface' CONFIG_INPUT_MOUSEDEV $CONFIG_INPUT
diff -urNXxpk 2.5.31-1/drivers/usb/Config.in 2.5.31-2/drivers/usb/Config.in
--- 2.5.31-1/drivers/usb/Config.in	2002-06-09 00:29:12.000000000 -0500
+++ 2.5.31-2/drivers/usb/Config.in	2002-08-13 21:23:18.000000000 -0500
@@ -1,17 +1,10 @@
 #
 # USB device configuration
 #
-mainmenu_option next_comment
-comment 'USB support'
-
-# ARM SA1111 chips have a non-PCI based "OHCI-compatible" USB host interface.
-if [ "$CONFIG_PCI" = "y" -o "$CONFIG_SA1111" = "y" ]; then
-   tristate 'Support for USB' CONFIG_USB
-else
-   define_bool CONFIG_USB n
-fi
-
 if [ "$CONFIG_USB" = "y" -o  "$CONFIG_USB" = "m" ]; then
+   mainmenu_option next_comment
+   comment 'USB support'
+
    source drivers/usb/core/Config.in
 
    source drivers/usb/host/Config.in
@@ -39,6 +32,5 @@
    dep_tristate '  USB Auerswald ISDN support (EXPERIMENTAL)' CONFIG_USB_AUERSWALD $CONFIG_USB $CONFIG_EXPERIMENTAL
    dep_tristate '  USB Diamond Rio500 support (EXPERIMENTAL)' CONFIG_USB_RIO500 $CONFIG_USB $CONFIG_EXPERIMENTAL
    dep_tristate '  Tieman Voyager USB Braille display support (EXPERIMENTAL)' CONFIG_USB_BRLVGER $CONFIG_USB $CONFIG_EXPERIMENTAL
-
+   endmenu
 fi
-endmenu
diff -urNXxpk 2.5.31-1/init/Config.in 2.5.31-2/init/Config.in
--- 2.5.31-1/init/Config.in	2002-06-09 00:27:27.000000000 -0500
+++ 2.5.31-2/init/Config.in	2002-08-13 22:03:13.000000000 -0500
@@ -9,13 +9,30 @@
 bool 'System V IPC' CONFIG_SYSVIPC
 bool 'BSD Process Accounting' CONFIG_BSD_PROCESS_ACCT
 bool 'Sysctl support' CONFIG_SYSCTL
-endmenu
 
-mainmenu_option next_comment
 comment 'Loadable module support'
 bool 'Enable loadable module support' CONFIG_MODULES
 if [ "$CONFIG_MODULES" = "y" ]; then
    bool '  Set version information on all module symbols' CONFIG_MODVERSIONS
    bool '  Kernel module loader' CONFIG_KMOD
 fi
+
+comment 'Other major subsystems'
+
+tristate 'SCSI support' CONFIG_SCSI
+
+# FIXME usb should depend on (PCI || SA1111) - but that causes other ordering problems
+tristate 'USB support' CONFIG_USB
+
+# FIXME parisc, sparc didn't include this menu before - any reason?
+if [ "$CONFIG_ARCH_S390" != "y" ]; then
+   tristate 'Input core support' CONFIG_INPUT
+fi
+
+# FIXME m68k, sparc* didn't include this either but we can't test for them
+if [ "$CONFIG_ARCH_S390" != "y" -a "$CONFIG_SUPERH" != "y" ]; then
+   tristate 'I2C support' CONFIG_I2C
+   dep_tristate '  I2C bit-banging interfaces' CONFIG_I2C_ALGOBIT $CONFIG_I2C
+fi
+
 endmenu

[patch] kernel config 3/N - move sound into drivers/media

[Peter Samuelson]

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]


Here's another one - this should fix the forward dependency between
CONFIG_SOUND and CONFIG_SOUND_ACI_MIXER, by moving the sound config
into the "Multimedia" menu - where I think it belongs anyway.

The big loser here is ARM - it no longer suppresses the sound card
question for the appropriate boards.  But it's just one question, so I
didn't sweat it too much.

[-- Attachment #2: 3.diff --]
[-- Type: text/plain, Size: 6348 bytes --]

diff -urNXxpk 2.5.31-2/arch/alpha/config.in 2.5.31w/arch/alpha/config.in
--- 2.5.31-2/arch/alpha/config.in	2002-08-13 22:07:23.000000000 -0500
+++ 2.5.31w/arch/alpha/config.in	2002-08-13 22:38:58.000000000 -0500
@@ -366,15 +366,6 @@
   endmenu
 fi
 
-mainmenu_option next_comment
-comment 'Sound'
-
-tristate 'Sound card support' CONFIG_SOUND
-if [ "$CONFIG_SOUND" != "n" ]; then
-  source sound/Config.in
-fi
-endmenu
-
 source drivers/usb/Config.in
 
 source net/bluetooth/Config.in
diff -urNXxpk 2.5.31-2/arch/arm/config.in 2.5.31w/arch/arm/config.in
--- 2.5.31-2/arch/arm/config.in	2002-08-13 22:07:42.000000000 -0500
+++ 2.5.31w/arch/arm/config.in	2002-08-13 22:43:26.000000000 -0500
@@ -630,22 +630,6 @@
    endmenu
 fi
 
-if [ "$CONFIG_ARCH_ACORN" = "y" -o \
-     "$CONFIG_ARCH_CLPS7500" = "y" -o \
-     "$CONFIG_ARCH_TBOX" = "y" -o \
-     "$CONFIG_ARCH_SHARK" = "y" -o \
-     "$CONFIG_ARCH_SA1100" = "y" -o \
-     "$CONFIG_PCI" = "y" ]; then
-   mainmenu_option next_comment
-   comment 'Sound'
-
-   tristate 'Sound card support' CONFIG_SOUND
-   if [ "$CONFIG_SOUND" != "n" ]; then
-      source sound/Config.in
-   fi
-   endmenu
-fi
-
 source drivers/misc/Config.in
 
 source drivers/usb/Config.in
diff -urNXxpk 2.5.31-2/arch/cris/config.in 2.5.31w/arch/cris/config.in
--- 2.5.31-2/arch/cris/config.in	2002-08-13 22:08:01.000000000 -0500
+++ 2.5.31w/arch/cris/config.in	2002-08-13 22:43:45.000000000 -0500
@@ -205,15 +205,6 @@
 
 source fs/Config.in
 
-mainmenu_option next_comment
-comment 'Sound'
-
-tristate 'Sound card support' CONFIG_SOUND
-if [ "$CONFIG_SOUND" != "n" ]; then
-  source sound/Config.in
-fi
-endmenu
-
 source drivers/usb/Config.in
 
 mainmenu_option next_comment
diff -urNXxpk 2.5.31-2/arch/i386/config.in 2.5.31w/arch/i386/config.in
--- 2.5.31-2/arch/i386/config.in	2002-08-13 22:05:49.000000000 -0500
+++ 2.5.31w/arch/i386/config.in	2002-08-13 23:06:04.000000000 -0500
@@ -385,15 +385,6 @@
    endmenu
 fi
 
-mainmenu_option next_comment
-comment 'Sound'
-
-tristate 'Sound card support' CONFIG_SOUND
-if [ "$CONFIG_SOUND" != "n" ]; then
-   source sound/Config.in
-fi
-endmenu
-
 source drivers/usb/Config.in
 
 source net/bluetooth/Config.in
diff -urNXxpk 2.5.31-2/arch/ia64/config.in 2.5.31w/arch/ia64/config.in
--- 2.5.31-2/arch/ia64/config.in	2002-08-13 22:08:38.000000000 -0500
+++ 2.5.31w/arch/ia64/config.in	2002-08-13 22:44:28.000000000 -0500
@@ -217,15 +217,6 @@
 
 if [ "$CONFIG_IA64_HP_SIM" = "n" ]; then
 
-mainmenu_option next_comment
-comment 'Sound'
-
-tristate 'Sound card support' CONFIG_SOUND
-if [ "$CONFIG_SOUND" != "n" ]; then
-  source sound/Config.in
-fi
-endmenu
-
 source drivers/usb/Config.in
 
 source lib/Config.in
diff -urNXxpk 2.5.31-2/arch/mips/config.in 2.5.31w/arch/mips/config.in
--- 2.5.31-2/arch/mips/config.in	2002-08-13 22:09:54.000000000 -0500
+++ 2.5.31w/arch/mips/config.in	2002-08-13 22:47:58.000000000 -0500
@@ -471,17 +471,6 @@
    endmenu
 fi
 
-if [ "$CONFIG_DECSTATION" != "y" ]; then
-   mainmenu_option next_comment
-   comment 'Sound'
-
-   tristate 'Sound card support' CONFIG_SOUND
-   if [ "$CONFIG_SOUND" != "n" ]; then
-      source sound/Config.in
-   fi
-   endmenu
-fi
-
 if [ "$CONFIG_SGI_IP22" = "y" ]; then
    source drivers/sgi/Config.in
 fi
diff -urNXxpk 2.5.31-2/arch/mips64/config.in 2.5.31w/arch/mips64/config.in
--- 2.5.31-2/arch/mips64/config.in	2002-08-13 22:10:16.000000000 -0500
+++ 2.5.31w/arch/mips64/config.in	2002-08-13 22:48:17.000000000 -0500
@@ -219,15 +219,6 @@
    define_bool CONFIG_KCORE_ELF y
 fi
 
-mainmenu_option next_comment
-comment 'Sound'
-
-tristate 'Sound card support' CONFIG_SOUND
-if [ "$CONFIG_SOUND" != "n" ]; then
-   source sound/Config.in
-fi
-endmenu
-
 if [ "$CONFIG_SGI_IP22" = "y" ]; then
    source drivers/sgi/Config.in
 fi
diff -urNXxpk 2.5.31-2/arch/ppc/config.in 2.5.31w/arch/ppc/config.in
--- 2.5.31-2/arch/ppc/config.in	2002-08-13 22:14:09.000000000 -0500
+++ 2.5.31w/arch/ppc/config.in	2002-08-13 22:54:57.000000000 -0500
@@ -558,15 +558,6 @@
 
 source fs/Config.in
 
-mainmenu_option next_comment
-comment 'Sound'
-tristate 'Sound card support' CONFIG_SOUND
-if [ "$CONFIG_SOUND" != "n" ]; then
-   source sound/oss/dmasound/Config.in
-   source sound/Config.in
-fi
-endmenu
-
 if [ "$CONFIG_8xx" = "y" ]; then
    source arch/ppc/8xx_io/Config.in
 fi
diff -urNXxpk 2.5.31-2/arch/ppc64/config.in 2.5.31w/arch/ppc64/config.in
--- 2.5.31-2/arch/ppc64/config.in	2002-08-13 22:14:24.000000000 -0500
+++ 2.5.31w/arch/ppc64/config.in	2002-08-13 22:56:14.000000000 -0500
@@ -197,15 +197,6 @@
 
 source fs/Config.in
 
-mainmenu_option next_comment
-comment 'Sound'
-tristate 'Sound card support' CONFIG_SOUND
-if [ "$CONFIG_SOUND" != "n" ]; then
-   source sound/Config.in
-fi
-
-endmenu
-
 source drivers/usb/Config.in
 
 source net/bluetooth/Config.in
diff -urNXxpk 2.5.31-2/arch/sh/config.in 2.5.31w/arch/sh/config.in
--- 2.5.31-2/arch/sh/config.in	2002-08-13 22:11:50.000000000 -0500
+++ 2.5.31w/arch/sh/config.in	2002-08-13 22:56:45.000000000 -0500
@@ -348,16 +348,6 @@
    endmenu
 fi
 
-
-mainmenu_option next_comment
-comment 'Sound'
-
-tristate 'Sound card support' CONFIG_SOUND
-if [ "$CONFIG_SOUND" != "n" ]; then
-   source sound/Config.in
-fi
-endmenu
-
 mainmenu_option next_comment
 comment 'Kernel hacking'
 
diff -urNXxpk 2.5.31-2/arch/x86_64/config.in 2.5.31w/arch/x86_64/config.in
--- 2.5.31-2/arch/x86_64/config.in	2002-08-13 22:11:44.000000000 -0500
+++ 2.5.31w/arch/x86_64/config.in	2002-08-13 22:57:49.000000000 -0500
@@ -199,15 +199,6 @@
    endmenu
 fi
 
-mainmenu_option next_comment
-comment 'Sound'
-
-tristate 'Sound card support' CONFIG_SOUND
-if [ "$CONFIG_SOUND" != "n" ]; then
-   source sound/Config.in
-fi
-endmenu
-
 source drivers/usb/Config.in
 
 source net/bluetooth/Config.in
diff -urNXxpk 2.5.31-2/drivers/media/Config.in 2.5.31w/drivers/media/Config.in
--- 2.5.31-2/drivers/media/Config.in	2002-06-09 00:29:41.000000000 -0500
+++ 2.5.31w/drivers/media/Config.in	2002-08-13 23:19:28.000000000 -0500
@@ -4,6 +4,12 @@
 mainmenu_option next_comment
 comment 'Multimedia devices'
 
+tristate 'Sound card support' CONFIG_SOUND
+if [ "$CONFIG_SOUND" != "n" ]; then
+   source sound/Config.in
+   source sound/oss/dmasound/Config.in
+fi
+
 tristate 'Video For Linux' CONFIG_VIDEO_DEV
 if [ "$CONFIG_VIDEO_DEV" != "n" ]; then
    source drivers/media/video/Config.in

Re: [patch] kernel config 3/N - move sound into drivers/media

[Kai Germaschewski]

On Tue, 13 Aug 2002, Peter Samuelson wrote:

> Here's another one - this should fix the forward dependency between
> CONFIG_SOUND and CONFIG_SOUND_ACI_MIXER, by moving the sound config
> into the "Multimedia" menu - where I think it belongs anyway.

Hmmh, makes sense to me, but there will probably be people complaining 
"sound config has disappeared for me" ;)

> The big loser here is ARM - it no longer suppresses the sound card
> question for the appropriate boards.  But it's just one question, so I
> didn't sweat it too much.

Well, I think that's okay, but you should check back with _rmk_.

What I like about that patch is that it actually removes duplicated code. 
I think that's exactly where this effort should start. For example, the 
SCSI patch didn't do this, though AFAICS it would be nicely possible to 
unconditionally source drivers/scsi/Config.in and then have the if in 
there.

These are trivial changes, and they make it easier to see what's happening 
in the patches which actually change behavior. Taking that a step further, 
this should also be a nice opportunity to introduce drivers/Config.in and 
remove even more duplication from arch/$ARCH/config.in. It comes of the 
cost of testing for the architecture, since e.g. s390 does not want to 
include most of drivers/*, but that means we'd actually collect this 
knowledge at a centralized place.

Introducing drivers/Config.in could be done nicely piecemeal as well, 
without any change in behavior which is always good. It would also provide 
a possibility to not lose the ARM knowledge.

I think it's basically just a question of taste if you prefer to initial 
global subsystem question in drivers/Config.in or 
drivers/<subsys>/Config.in.

drivers/isdn/Config.in starts with

	mainmenu_option next_comment
	comment 'ISDN subsystem'
	if [ "$CONFIG_NET" != "n" ]; then
	   bool 'ISDN support' CONFIG_ISDN_BOOL

	   if [ "$CONFIG_ISDN_BOOL" = "y" ]; then
	      mainmenu_option next_comment

since I did not like having that duplicated in each arch/*/config.in. It
also makes sense in the "have as much information as possible about a
subsystem located in one place (drivers/<subsys>)". By the way, if you do
these kind of changes, also check Config.help, you may be able to remove
duplicated entries there as well ;)

The drawbacks of that solution as opposed to having the above in 
drivers/Config.in and ending with source "drivers/isdn/Config.in" are:
o We need to source all the Config.in files even when the subsys gets 
  disabled, since we cannot know that beforehand
o The trivial patches moving statements like the above into the 
  subsys/Config.in means that all of that file should be indented, which
  makes the patches look really large, even though they change very 
  little.

I have no strong opinion either way, but I'd certainly like 
a drivers/Config.in.

Oh, what I don't like about your patches: You don't include them inline, 
so I cannot easily (R)eply to them and have them quoted ;)

--Kai

Re: [patch] kernel config 3/N - move sound into drivers/media

[Peter Samuelson]

  [I wrote]
> > Here's another one - this should fix the forward dependency
> > between CONFIG_SOUND and CONFIG_SOUND_ACI_MIXER, by moving the
> > sound config into the "Multimedia" menu - where I think it belongs
> > anyway.

[Kai Germaschewski]
> Hmmh, makes sense to me, but there will probably be people
> complaining "sound config has disappeared for me" ;)

You are probably right.  I still think it's the right thing to do. (:
I do *not* like the recent proliferation of toplevel menu entries.

> Well, I think that's okay, but you should check back with _rmk_.

True.  The trouble with this sort of work is that you *have* to touch
all the architectures, and sometimes change the behavior somewhat.
That can mean stepping on toes now and then.

> What I like about that patch is that it actually removes duplicated
> code.  I think that's exactly where this effort should start. For
> example, the SCSI patch didn't do this, though AFAICS it would be
> nicely possible to unconditionally source drivers/scsi/Config.in and
> then have the if in there.

I thought about that - but didn't want to re-indent the whole file.  I
hate doing that. (:

Also, there's a *reason* every arch has a separate config.in file -
for maximum flexibility without putting lots of ifdefs in common code.
To a certain extent I agree with you and I wish it were possible to
eliminate the arch/*/config.in entirely, but it's not.  ESR tried it
with CML2 and was slapped down by Linus himself, as I recall.

I don't want my humble efforts to end up the same way CML2 did.  For
that reason I'm trying very hard to make only small, incremental,
obvious changes.  Perhaps I'm a bit *too* timid.

> It comes of the cost of testing for the architecture, since
> e.g. s390 does not want to include most of drivers/*, but that means
> we'd actually collect this knowledge at a centralized place.

What we need is an easy way to check for any arch.  CONFIG_ARCH_S390
is the right idea (though s390x sets it as well, not sure if that's
good or bad).  Then again, such checks polluting the common code is
exactly what the current system (with all its cut/paste code in
arch/*/config.in) is supposed to prevent.  Perhaps The Powers That Be
like the status quo.

> Introducing drivers/Config.in could be done nicely piecemeal as
> well, without any change in behavior which is always good. It would
> also provide a possibility to not lose the ARM knowledge.

Hmmmm ... I didn't see any clean way to keep the arm test.  Thinking
about it some more, I suppose one could do

  if [ "$CONFIG_ARM" = "y" ]; then
    if [ ... ]; then
      tristate CONFIG_SOUND
    fi
  else
    tristate CONFIG_SOUND
  fi

It's still not pretty, but should work.  I think I'll put that in
drivers/media/Config.in.

> By the way, if you do these kind of changes, also check Config.help,
> you may be able to remove duplicated entries there as well ;)

I'd been avoiding Config.help - I was afraid if I looked in it I would
find entries I would have to move from one dir to another. (:

> I have no strong opinion either way, but I'd certainly like a
> drivers/Config.in.

Agreed.

> Oh, what I don't like about your patches: You don't include them
> inline, so I cannot easily (R)eply to them and have them quoted ;)

Sorry about that - I agree.  I only attached patches when I had more
than one for a single mail, and then I forgot to switch back.  Must
recompile self with -finline-patches....

Peter

Re: [kbuild-devel] Re: [patch] kernel config 3/N - move sound into drivers/media

[Arnd Bergmann]

On Wednesday 14 August 2002 07:49, Peter Samuelson wrote:
> [Kai Germaschewski]
> > It comes of the cost of testing for the architecture, since
> > e.g. s390 does not want to include most of drivers/*, but that means
> > we'd actually collect this knowledge at a centralized place.
>
> What we need is an easy way to check for any arch.  CONFIG_ARCH_S390
> is the right idea (though s390x sets it as well, not sure if that's
> good or bad). 

It's not logical, but it tends to help because it's what's meant most
of the time. I don't know a single place in the kernel where you want
to test for (CONFIG_ARCH_S390 && !CONFIG_ARCH_S390X).

Rather than making everything depend on CONFIG_ARCH_THIS && CONFIG_ARCH_THAT,
I'd prefer if every driver depended on its bus type. With the new driver
model, every driver has a clearly defined bus type and driver class,
so it would be logical to have that driver option exactly when these two
are enabled. Of course, that probably means a huge amount of work but it 
helps avoid problems when a new architecture is added or an existing one
gets a new bus.
E.g., s390 used to have no support for SCSI, but with the zfcp driver
we enable drivers/scsi/Config.in, so now we get a lot of questions about
drivers that won't work. Enclosing the drivers in "CONFIG_ARCH_s390" != "y"
does help us, but it would still be wrong to do that for a Sparc kernel
that supports some of the PCI cards but not the ISA ones.

	Arnd <><

S390 vs S390x, was Re: [kbuild-devel] Re: [patch] kernel config 3/N - move sound into drivers/media

[Christoph Hellwig]

On Wed, Aug 14, 2002 at 12:56:27PM +0200, Arnd Bergmann wrote:
> It's not logical, but it tends to help because it's what's meant most
> of the time. I don't know a single place in the kernel where you want
> to test for (CONFIG_ARCH_S390 && !CONFIG_ARCH_S390X).

BTW, ho much differences are between arch/s390 and arch/s390x?  Is there
any chance it could use the same #ifdef __LP64__ trick parisc uses for
its 32 and 64bit versions?  so far every file I've looked at was duplicated
exactly in s390 and s390x.

Re: S390 vs S390x, was Re: [kbuild-devel] Re: [patch] kernel config 3/N - move sound into drivers/media

[Arnd Bergmann]

On Wednesday 14 August 2002 14:20, Christoph Hellwig wrote:
> On Wed, Aug 14, 2002 at 12:56:27PM +0200, Arnd Bergmann wrote:
> > It's not logical, but it tends to help because it's what's meant most
> > of the time. I don't know a single place in the kernel where you want
> > to test for (CONFIG_ARCH_S390 && !CONFIG_ARCH_S390X).
>
> BTW, ho much differences are between arch/s390 and arch/s390x?  Is there
> any chance it could use the same #ifdef __LP64__ trick parisc uses for
> its 32 and 64bit versions?  so far every file I've looked at was duplicated
> exactly in s390 and s390x.

The biggest differences are that s390 has an fpu emulation while s390x has
emulation for s390 binaries. These are not an issue -- just an ifdef for 
the files. The other problem is that the assembly opcodes are different 
-- 64 bit instructions have a 'g' in the opcode so you need two versions
of each .S file and #ifdefs for each inline asm.

The remaining differences are stuff that depends on sizeof(void*) and some
more backwards compatible system calls for s390, the diff -u between these
is ~300kb out of 500kb of the common .c files. I'd expect this to become
at least 50 #ifdefs plus some moved files (e.g. s390x/kernel/ptrace.c ->
s390/kernel/ptrace64.c) and an audit of all places where the difference
is nonobvious.

I also had the idea to unify the two (actually have tried a few months ago
but did not bring it to a clean end), but was not really sure if it was a 
good one. Do you think it is worth the effort of merging the existing code
and changing all the documentation referring to arch/s390x?

We do indeed want to merge include/asm-s390 include/asm-s390x, which would
help building a compiler that supports both on s390x, but nobody has
worked on that recently -- I had done this for ~2.5.8 but it soon got
outdated.

	Arnd <><

Re: S390 vs S390x, was Re: [kbuild-devel] Re: [patch] kernel config 3/N - move sound into drivers/media

[Christoph Hellwig]

On Wed, Aug 14, 2002 at 07:21:58PM +0200, Arnd Bergmann wrote:
> I also had the idea to unify the two (actually have tried a few months ago
> but did not bring it to a clean end), but was not really sure if it was a 
> good one. Do you think it is worth the effort of merging the existing code

I think it's worth the effort.  Especially if IBM wants to keep the 32 (31)bit
port alife long-term.  Having two codebases that are mostly the same doesn't
sound like a good idea for fix propagation to me.

> and changing all the documentation referring to arch/s390x?

How much documentation outside the kernel tree knows about it?

> We do indeed want to merge include/asm-s390 include/asm-s390x, which would
> help building a compiler that supports both on s390x,

I think it's a good idea but don't understand the compiler depency.  Why
do you need asm-s390 and asm-s390x to be the same to have an compiler that
works for 32bit and 64bit mode?  Today e.g. the sparc and x86 compilers
can support both modes with very different kernel headers.

I don't see how you want to make the s390x port refer to include/asm-s390
easily when ARCH is still s390x..

Re: S390 vs S390x, was Re: [kbuild-devel] Re: [patch] kernel config 3/N - move sound into drivers/media

[Arnd Bergmann]

On Wednesday 14 August 2002 20:16, Christoph Hellwig wrote:
> > and changing all the documentation referring to arch/s390x?
>
> How much documentation outside the kernel tree knows about it?

There are some books about Linux on s390/zSeries that are supposed
to be kept up to date with each of our "code drops" that happen
about twice a year. There probably isn't that much reference
to "s390x" since that's not an official IBM marketing term, but 
still they'd have to be audited. OTOH, there are other far bigger
documentation changes for 2.6, so having only one architecture might 
actually save some duplicated work even for the documentation.

> > We do indeed want to merge include/asm-s390 include/asm-s390x, which
> > would help building a compiler that supports both on s390x,
>
> I think it's a good idea but don't understand the compiler depency.  Why
> do you need asm-s390 and asm-s390x to be the same to have an compiler that
> works for 32bit and 64bit mode?  Today e.g. the sparc and x86 compilers
> can support both modes with very different kernel headers.

Ok. So what happens there if a user space program e.g. does #include
<asm/page.h>? Where does that go instead of /usr/include/asm/page.h?

	Arnd <><

Re: S390 vs S390x, was Re: [kbuild-devel] Re: [patch] kernel config 3/N - move sound into drivers/media

[Christoph Hellwig]

On Wed, Aug 14, 2002 at 11:18:13PM +0200, Arnd Bergmann wrote:
> Ok. So what happens there if a user space program e.g. does #include
> <asm/page.h>? Where does that go instead of /usr/include/asm/page.h?

First:  Userspace including asm/* headers is BROKEN.  But as we have lots
of broken userspace we still to have to support that for some time.  The
solution is to have a wrapper that includes either asm-<b> or asm-<a>
depending on some cpp symbol.  Look at redhat's old kernel rpms for an
example.

Re: S390 vs S390x, was Re: [kbuild-devel] Re: [patch] kernel config 3/N - move sound into drivers/media

[Arnd Bergmann]

On Wednesday 14 August 2002 21:22, Christoph Hellwig wrote:
> On Wed, Aug 14, 2002 at 11:18:13PM +0200, Arnd Bergmann wrote:
> > Ok. So what happens there if a user space program e.g. does #include
> > <asm/page.h>? Where does that go instead of /usr/include/asm/page.h?
>
> First:  Userspace including asm/* headers is BROKEN.  But as we have lots
> of broken userspace we still to have to support that for some time.  The
And since in particular glibc is still part of this brokenness, every
sufficiently large user space program accesses them in some way...

> solution is to have a wrapper that includes either asm-<b> or asm-<a>
> depending on some cpp symbol.  Look at redhat's old kernel rpms for an
> example.
ok, so it does not work with the default kernel headers copied to 
/usr/include but some extra tweaking. Making the two include/asm-*/ trees
identical is just another way of getting to the same result.

	Arnd <><

Re: [patch] kernel config 3/N - move sound into drivers/media

[Greg Banks]

Kai Germaschewski wrote:
> 
> On Tue, 13 Aug 2002, Peter Samuelson wrote:
> 
> I think that's exactly where this effort should start. For example, the
> SCSI patch didn't do this, though AFAICS it would be nicely possible to
> unconditionally source drivers/scsi/Config.in and then have the if in
> there.

I like that idea.

> this should also be a nice opportunity to introduce drivers/Config.in and
> remove even more duplication from arch/$ARCH/config.in. It comes of the
> cost of testing for the architecture, since e.g. s390 does not want to
> include most of drivers/*, but that means we'd actually collect this
> knowledge at a centralized place.

<gentle-irony>Oh no the dreaded unified arch tree!</gentle-irony>

Seriously, I think this is perhaps a bit brave in the short term.

> o The trivial patches moving statements like the above into the
>   subsys/Config.in means that all of that file should be indented, which
>   makes the patches look really large, even though they change very
>   little.

I wouldn't be too worried about indentation, it's quite loosely followed
already.  In fact better to do one patch that does the move and a second
larger but provably-trivial patch that fixes up the indentation.

> I have no strong opinion either way, but I'd certainly like
> a drivers/Config.in.

I think it's a great idea whose time has not yet come.

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.

Re: [patch] kernel config 3/N - move sound into drivers/media

[Greg Banks]

Peter Samuelson wrote:
> 
> Here's another one - this should fix the forward dependency between
> CONFIG_SOUND and CONFIG_SOUND_ACI_MIXER, by moving the sound config
> into the "Multimedia" menu - where I think it belongs anyway.
> 
>  [...]
> -if [ "$CONFIG_ARCH_ACORN" = "y" -o \
> -     "$CONFIG_ARCH_CLPS7500" = "y" -o \
> -     "$CONFIG_ARCH_TBOX" = "y" -o \
> -     "$CONFIG_ARCH_SHARK" = "y" -o \
> -     "$CONFIG_ARCH_SA1100" = "y" -o \
> -     "$CONFIG_PCI" = "y" ]; then
> -   mainmenu_option next_comment
> -   comment 'Sound'
> -
> -   tristate 'Sound card support' CONFIG_SOUND
> -   if [ "$CONFIG_SOUND" != "n" ]; then
> -      source sound/Config.in
> -   fi
> -   endmenu
> -fi
> -
>  [...]
> -if [ "$CONFIG_DECSTATION" != "y" ]; then
> -   mainmenu_option next_comment
> -   comment 'Sound'
> -
> -   tristate 'Sound card support' CONFIG_SOUND
> -   if [ "$CONFIG_SOUND" != "n" ]; then
> -      source sound/Config.in
> -   fi
> -   endmenu
> -fi
> -
> [...]
> +tristate 'Sound card support' CONFIG_SOUND
> +if [ "$CONFIG_SOUND" != "n" ]; then
> +   source sound/Config.in
> +   source sound/oss/dmasound/Config.in
> +fi
> +
>  tristate 'Video For Linux' CONFIG_VIDEO_DEV
>  if [ "$CONFIG_VIDEO_DEV" != "n" ]; then
>     source drivers/media/video/Config.in

Perhaps you might want to be careful about losing existing behaviour.

This patch makes the following improvements:

--- s-2.5.31-sam2.txt	Wed Aug 14 15:56:09 2002
+++ s-2.5.31-sam3.txt	Wed Aug 14 16:24:25 2002
@@ -279,3 +279,3 @@
     1      CONFIG_PCI_NAMES
-329    undeclared-symbol
+328    undeclared-symbol
     76     CONFIG_OBSOLETE
@@ -294,4 +294,4 @@
     11     CONFIG_SA
-    4      CONFIG_ARCH_TBOX
     3      CONFIG_ARCH_FTVPCI
+    3      CONFIG_ARCH_TBOX
     2      CONFIG_ARCH_NEXUSPCI
@@ -314,3 +314,3 @@
     1      CONFIG_PROC_FS
-134    forward-reference
+123    forward-reference
     43     CONFIG_PROC_FS
@@ -321,3 +321,2 @@
     11     CONFIG_ISDN_DRV_EICON_OLD
-    11     CONFIG_SOUND_ACI_MIXER
     6      CONFIG_PCI
@@ -330,6 +329,5 @@
     1      CONFIG_ZORRO
-34     forward-dependancy
+23     forward-dependancy
     11     CONFIG_ISDN_CAPI
     11     CONFIG_PROC_FS
-    11     CONFIG_SOUND_ACI_MIXER
     1      CONFIG_BLK_DEV_SD
@@ -394,2 +392,2 @@
 10     different-compound-type
-3055   total
+3032   total

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.

Re: [patch] kernel config 3/N - move sound into drivers/media

[Russell King]

On Tue, Aug 13, 2002 at 11:35:58PM -0500, Peter Samuelson wrote:
> The big loser here is ARM - it no longer suppresses the sound card
> question for the appropriate boards.  But it's just one question, so I
> didn't sweat it too much.

I'd be tempted to drop that set of tests, and just rely on the per-driver
stuff, where its sane to do so.  There's no way we can special case all
the drivers out there for each machine type in the generic config files.
That is the route to madness.

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

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

[Greg Banks]

Peter Samuelson wrote:
> 
> > > [...]  Perhaps a "kernel subsystems" submenu under "general setup",
> > > or even as a toplevel menu.
> >
> > Sounds like a good idea.  You could put CONFIG_SERIAL and CONFIG_PCMCIA
> > in there too.
> 
> CONFIG_SERIAL and CONFIG_PCMCIA didn't generate any noise, though.

warning:drivers/parport/Config.in:14:forward declared symbol "CONFIG_SERIAL" compared ambiguously to "n"
warning:drivers/parport/Config.in:14:forward reference to "CONFIG_SERIAL"
warning:drivers/parport/Config.in:15:forward reference to "CONFIG_SERIAL"


warning:drivers/char/Config.in:193:forward declared symbol "CONFIG_PCMCIA" compared ambiguously to "n"
warning:drivers/char/pcmcia/Config.in:8:forward declared symbol "CONFIG_PCMCIA" used in dependency list for "CONFIG_SYNCLINK_CS"
warning:drivers/ide/Config.in:19:forward declared symbol "CONFIG_PCMCIA" used in dependency list for "CONFIG_BLK_DEV_IDECS"
warning:drivers/isdn/hardware/avm/Config.in:20:forward declared symbol "CONFIG_PCMCIA" used in dependency list for "CONFIG_ISDN_DRV_AVMB1_AVM_CS"
[...30-odd more...]

> Here's a start.  It looks a little hacky but it does fix real issues.
> I decided to combine "general setup", "module config" and "major
> subsystems" - the latter needs to come after modules but really
> belongs with general setup.  Eh?
> 
> I think the first patch belongs on trivial@rustcorp - what's the
> protocol there, just an email cc?  Attach or inline?  etc.

I've been inlining.  Use a unique subject line for when you get status
updates.

The diffs look ok to me, except...

> +# FIXME usb should depend on (PCI || SA1111) - but that causes other ordering problems
> +tristate 'USB support' CONFIG_USB

Nasty.

> +
> +# FIXME parisc, sparc didn't include this menu before - any reason?

I'd suggest preserving that behaviour.  CONFIG_PARISC for parisc.

> +if [ "$CONFIG_ARCH_S390" != "y" ]; then
> +   tristate 'Input core support' CONFIG_INPUT
> +fi
> +
> +# FIXME m68k, sparc* didn't include this either but we can't test for them

I still don't know the right way to test for m68k, but for sparc* you
need to test CONFIG_SPARC32 and CONFIG_SPARC64.

> +   dep_tristate '  I2C bit-banging interfaces' CONFIG_I2C_ALGOBIT $CONFIG_I2C
> +fi
> +
>  endmenu

Are you sure want this one there?


Your first patch made the following improvements

--- s-2.5.31.txt	Wed Aug 14 15:51:44 2002
+++ s-2.5.31-sam1.txt	Wed Aug 14 15:52:48 2002
@@ -313,8 +313,6 @@
     1      CONFIG_PROC_FS
-287    forward-reference
-    48     CONFIG_USB
+251    forward-reference
+    54     CONFIG_USB
     43     CONFIG_PROC_FS
     31     CONFIG_SCSI
-    24     CONFIG_INPUT
-    18     CONFIG_SOUND_GAMEPORT
     16     CONFIG_I2C
@@ -335,7 +333,5 @@
     1      CONFIG_ZORRO
-152    forward-dependancy
-    32     CONFIG_USB
+116    forward-dependancy
+    35     CONFIG_USB
     31     CONFIG_SCSI
-    21     CONFIG_INPUT
-    18     CONFIG_SOUND_GAMEPORT
     11     CONFIG_ISDN_CAPI
@@ -408,2 +404,2 @@
 8      different-compound-type
-3362   total
+3290   total

Your second patch made the following improvements (well,
mostly improvements).

--- s-2.5.31-sam1.txt	Wed Aug 14 15:52:48 2002
+++ s-2.5.31-sam2.txt	Wed Aug 14 15:56:09 2002
@@ -206,3 +206,3 @@
     1      CONFIG_WILLOW
-61     different-parent
+66     different-parent
     7      CONFIG_NET_FC
@@ -210,2 +210,5 @@
     2      CONFIG_FB
+    2      CONFIG_KMOD
+    2      CONFIG_MODULES
+    2      CONFIG_MODVERSIONS
     2      CONFIG_RTC
@@ -251,5 +254,4 @@
     1      CONFIG_SCC_ENET
-    1      CONFIG_USB
     1      CONFIG_USE_MDIO
-36     overlapping-definitions
+38     overlapping-definitions
     11     CONFIG_SOUND_CMPCI_FMIO
@@ -261,2 +263,3 @@
     2      CONFIG_PARPORT
+    2      CONFIG_USB
     1      CONFIG_ALPHA_AVANTI
@@ -301,3 +304,3 @@
     1      CONFIG_XSCALE_PMU_TIMER
-75     forward-compared-to-n
+59     forward-compared-to-n
     13     CONFIG_INPUT_GAMEPORT
@@ -306,4 +309,2 @@
     12     CONFIG_PCMCIA
-    10     CONFIG_USB
-    6      CONFIG_I2C
     3      CONFIG_CARDBUS
@@ -313,8 +314,4 @@
     1      CONFIG_PROC_FS
-251    forward-reference
-    54     CONFIG_USB
+134    forward-reference
     43     CONFIG_PROC_FS
-    31     CONFIG_SCSI
-    16     CONFIG_I2C
-    16     CONFIG_I2C_ALGOBIT
     14     CONFIG_SCSI_AIC7XXX_OLD
@@ -333,5 +330,3 @@
     1      CONFIG_ZORRO
-116    forward-dependancy
-    35     CONFIG_USB
-    31     CONFIG_SCSI
+34     forward-dependancy
     11     CONFIG_ISDN_CAPI
@@ -339,10 +334,8 @@
     11     CONFIG_SOUND_ACI_MIXER
-    9      CONFIG_I2C_ALGOBIT
-    7      CONFIG_I2C
     1      CONFIG_BLK_DEV_SD
-823    undeclared-dependancy
+794    undeclared-dependancy
     94     CONFIG_PCI
     69     CONFIG_ISA
-    60     CONFIG_X86
     58     CONFIG_ALL_PPC
+    54     CONFIG_X86
     48     CONFIG_ARCH_ACORN
@@ -361,3 +354,2 @@
     11     CONFIG_ATARI
-    11     CONFIG_I2C
     11     CONFIG_MAC
@@ -384,6 +376,4 @@
     8      CONFIG_SBUS
-    7      CONFIG_I2C_ALGOBIT
     6      CONFIG_MTD
     6      CONFIG_SOUND_GAMEPORT
-    5      CONFIG_USB
     4      CONFIG_PARPORT
@@ -403,3 +393,3 @@
     1      CONFIG_SH_WDT
-8      different-compound-type
-3290   total
+10     different-compound-type
+3055   total



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.

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

[Russell King]

On Wed, Aug 14, 2002 at 04:01:18PM +1000, Greg Banks wrote:
> > CONFIG_SERIAL and CONFIG_PCMCIA didn't generate any noise, though.
> 
> warning:drivers/parport/Config.in:14:forward declared symbol "CONFIG_SERIAL" compared ambiguously to "n"
> warning:drivers/parport/Config.in:14:forward reference to "CONFIG_SERIAL"
> warning:drivers/parport/Config.in:15:forward reference to "CONFIG_SERIAL"

I'm probably going to end up sucking the stuff that uses CONFIG_SERIAL in
parport into drivers/serial in the near future, which should solve this
problem.

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

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

[Peter Samuelson]

[Greg Banks]
> warning:drivers/parport/Config.in:14:forward declared symbol "CONFIG_SERIAL" compared ambiguously to "n"
> warning:drivers/parport/Config.in:14:forward reference to "CONFIG_SERIAL"
> warning:drivers/parport/Config.in:15:forward reference to "CONFIG_SERIAL"
> 
> 
> warning:drivers/char/Config.in:193:forward declared symbol "CONFIG_PCMCIA" compared ambiguously to "n"
> warning:drivers/char/pcmcia/Config.in:8:forward declared symbol "CONFIG_PCMCIA" used in dependency list for "CONFIG_SYNCLINK_CS"
> warning:drivers/ide/Config.in:19:forward declared symbol "CONFIG_PCMCIA" used in dependency list for "CONFIG_BLK_DEV_IDECS"
> warning:drivers/isdn/hardware/avm/Config.in:20:forward declared symbol "CONFIG_PCMCIA" used in dependency list for "CONFIG_ISDN_DRV_AVMB1_AVM_CS"

Hmmm, either I missed those in your earlier messages, or you didn't
post them.

> > +# FIXME usb should depend on (PCI || SA1111) - but that causes other ordering problems
> > +tristate 'USB support' CONFIG_USB
> 
> Nasty.

Yeah, I don't see any clean fix for that one.

> > +# FIXME parisc, sparc didn't include this menu before - any reason?
> 
> I'd suggest preserving that behaviour.  CONFIG_PARISC for parisc.

...and CONFIG_SPARC32 for sparc.  Thanks.  I didn't notice
CONFIG_SPARC32 because it's not defined in time for init/config.in.
Time for another trivial patch....

> > +   dep_tristate '  I2C bit-banging interfaces' CONFIG_I2C_ALGOBIT $CONFIG_I2C
> > +fi
> > +
> >  endmenu
> 
> Are you sure want this one there?

I didn't like it either, but it's needed in a couple odd places.  What
would you suggest - moving the whole i2c menu up?

> Your first patch made the following improvements
> 
> --- s-2.5.31.txt	Wed Aug 14 15:51:44 2002
> +++ s-2.5.31-sam1.txt	Wed Aug 14 15:52:48 2002

Thanks, your "oracle" feedback is much appreciated.

> Your second patch made the following improvements (well,
> mostly improvements).
> 
> --- s-2.5.31-sam1.txt	Wed Aug 14 15:52:48 2002
> +++ s-2.5.31-sam2.txt	Wed Aug 14 15:56:09 2002
> @@ -206,3 +206,3 @@
>      1      CONFIG_WILLOW
> -61     different-parent
> +66     different-parent
>      7      CONFIG_NET_FC
> @@ -210,2 +210,5 @@
>      2      CONFIG_FB
> +    2      CONFIG_KMOD
> +    2      CONFIG_MODULES
> +    2      CONFIG_MODVERSIONS
>      2      CONFIG_RTC

What does that mean?  All I did there was to combine two toplevel
menus into one.  Did this do something bad?

> -36     overlapping-definitions
> +38     overlapping-definitions
>      11     CONFIG_SOUND_CMPCI_FMIO
> @@ -261,2 +263,3 @@
>      2      CONFIG_PARPORT
> +    2      CONFIG_USB

OK, I see CONFIG_USB in arch/cris/drivers/Config.in - is there another
instance I'm missing?

> -8      different-compound-type
> -3290   total
> +10     different-compound-type
> +3055   total

different-compound-type?

Peter

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

[Greg Banks]

Peter Samuelson wrote:
> 
> [Greg Banks]
> > [...CONFIG_SERIAL and CONFIG_PCMCIA warnings...]
> >
> Hmmm, either I missed those in your earlier messages, or you didn't
> post them.

Probably I didn't post them.  What I posted was a small subset of the full log.

> > > +   dep_tristate '  I2C bit-banging interfaces' CONFIG_I2C_ALGOBIT $CONFIG_I2C
> >
> > Are you sure want this one there?
> 
> I didn't like it either, but it's needed in a couple odd places.  What
> would you suggest - moving the whole i2c menu up?

Not all the way up to the new menu, but before the bits that depend on them,
which are in drivers/video/ drivers/media/video and drivers/ieee1394 IIRC.

> Thanks, your "oracle" feedback is much appreciated.

I'm hoping to have an RPM out this weekend so you can do the augury yourself.

> > @@ -210,2 +210,5 @@
> >      2      CONFIG_FB
> > +    2      CONFIG_KMOD
> > +    2      CONFIG_MODULES
> > +    2      CONFIG_MODVERSIONS
> >      2      CONFIG_RTC
> 
> What does that mean?  All I did there was to combine two toplevel
> menus into one.  Did this do something bad?

Apparently.  In the stock kernel:

warning:arch/mips/config.in:224:"CONFIG_KMOD" has overlapping definitions
warning:init/Config.in:19:location of previous definition
warning:arch/parisc/config.in:53:"CONFIG_KMOD" has overlapping definitions
warning:init/Config.in:19:location of previous definition

Did I mention Gordian knot?

> > -36     overlapping-definitions
> > +38     overlapping-definitions
> >      11     CONFIG_SOUND_CMPCI_FMIO
> > @@ -261,2 +263,3 @@
> >      2      CONFIG_PARPORT
> > +    2      CONFIG_USB
> 
> OK, I see CONFIG_USB in arch/cris/drivers/Config.in - is there another
> instance I'm missing?

There's two in the same file, lines 185 and 189.

> > -8      different-compound-type
> > -3290   total
> > +10     different-compound-type
> > +3055   total
> 
> different-compound-type?

Please ignore that one.  It's an artifact of the way I check for symbols
not declared anywhere at all, related to config.in's using the same banner
for a menu and a comment.

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.

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

[Peter Samuelson]

[Greg Banks]
> > > > +   dep_tristate '  I2C bit-banging interfaces' CONFIG_I2C_ALGOBIT $CONFIG_I2C
> > >
> > > Are you sure want this one there?
> > 
> > I didn't like it either, but it's needed in a couple odd places.  What
> > would you suggest - moving the whole i2c menu up?
> 
> Not all the way up to the new menu, but before the bits that depend on them,
> which are in drivers/video/ drivers/media/video and drivers/ieee1394 IIRC.

It should be possible to take I2C back out of init/Config.in, in that
case.  I'll do that in my tree.

> > > +    2      CONFIG_KMOD
> > > +    2      CONFIG_MODULES
> > > +    2      CONFIG_MODVERSIONS
> > >      2      CONFIG_RTC
> > 
> > What does that mean?  All I did there was to combine two toplevel
> > menus into one.  Did this do something bad?
> 
> Apparently.  In the stock kernel:
> 
> warning:arch/mips/config.in:224:"CONFIG_KMOD" has overlapping definitions
> warning:init/Config.in:19:location of previous definition
> warning:arch/parisc/config.in:53:"CONFIG_KMOD" has overlapping definitions
> warning:init/Config.in:19:location of previous definition

Weird.  These should have triggered all along - any idea why they
didn't?

Well, they're fixed in my tree.  It looks [trivial], but this one
makes me uneasy.  I mean, it's such an obvious bug - the toplevel
"Loadable module support" menu appears twice - that I almost think it
was somehow intentional.

> Did I mention Gordian knot?

Yes, I believe you did.  Does that make ESR Alexander the Great? (:

> > OK, I see CONFIG_USB in arch/cris/drivers/Config.in - is there another
> > instance I'm missing?
> 
> There's two in the same file, lines 185 and 189.

Right - they're mutually exclusive, so I thought it might only count
as one.  Anyway, fixed in my tree.

> related to config.in's using the same banner for a menu and a
> comment.

mainmenu_option next_comment ... now *there's* a bit of syntax that
needs to change.  Even config-language.txt agrees.

Peter

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

[Greg Banks]

Peter Samuelson wrote:
> 
> [Greg Banks]
> > > > +    2      CONFIG_KMOD
> > > > +    2      CONFIG_MODULES
> > > > +    2      CONFIG_MODVERSIONS
> > > >      2      CONFIG_RTC
> > >
> > > What does that mean?  All I did there was to combine two toplevel
> > > menus into one.  Did this do something bad?
> >
> > Apparently.  In the stock kernel:
> >
> > warning:arch/mips/config.in:224:"CONFIG_KMOD" has overlapping definitions
> > warning:init/Config.in:19:location of previous definition
> > warning:arch/parisc/config.in:53:"CONFIG_KMOD" has overlapping definitions
> > warning:init/Config.in:19:location of previous definition
> 
> Weird.  These should have triggered all along - any idea why they
> didn't?

Because you moved the items to a menu with a different name.

GCML2 issues the overlapping-definitions warning if the same item appears
twice in such a way that both definitions can be visible at the same time.
A sub-case is where the item appears twice unconditionally in the same menu,
which was happening before your change.  Another sub-case is where the item
appears twice unconditionally in different menus, which happened after your
change.  Hence overlapping-definitions warnings for CONFIG_KMOD et al did not
appear in the diff of summaries.

GCML2 issues the different-parent warning when an item appears in two
different menu parents, regardless of conditions.  Before your change, the
two identically named menus were merged into one node (this behaviour is
very necessary for reasons too complex to go into here) so the two definitions
of CONFIG_KMOD had the same parent.  After your change, they had different
parents, hence the new warnings.

> Well, they're fixed in my tree.  It looks [trivial], but this one
> makes me uneasy.  I mean, it's such an obvious bug - the toplevel
> "Loadable module support" menu appears twice - that I almost think it
> was somehow intentional.

There are many [trivial] errors.  My favourite is CONFIG_SOUND_CMPCI_FMIO.

> > Did I mention Gordian knot?
> 
> Yes, I believe you did.  Does that make ESR Alexander the Great? (:

Given the noise of his arrival and the speed of his departure...Darius.

> > related to config.in's using the same banner for a menu and a
> > comment.
> 
> mainmenu_option next_comment ... now *there's* a bit of syntax that
> needs to change.  Even config-language.txt agrees.

That would be great, but the problem is related to the way comments are
defined in CML2, which doesn't quite fit in CML1.

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.

Re: [patch] config language dep_* enhancements

[Kai Germaschewski]

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

Re: [patch] config language dep_* enhancements

[Peter Samuelson]

[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

Re: [patch] config language dep_* enhancements

[Greg Banks]

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.

Re: [patch] config language dep_* enhancements

[Peter Samuelson]

  [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

Re: [patch] config language dep_* enhancements

[Greg Banks]

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.

Re: [patch] config language dep_* enhancements

[Peter Samuelson]

[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

Re: [patch] config language dep_* enhancements

[Kai Germaschewski]

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

Re: [patch] config language dep_* enhancements

[Greg Banks]

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.

Re: [patch] config language dep_* enhancements

[Roman Zippel]

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

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

[Greg Banks]

Roman Zippel wrote:
> 
> Hi,
> 
> On Tue, 13 Aug 2002, Peter Samuelson wrote:
> 
> > Mutating the language, long-term, so that it looks less like sh [...]
> 
> That doesn't solve any of the more fundamental problems.

Correct, it doesn't.

> 1) We still have 3 config parsers, which produce slightly different
> .config files.

Yes.

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

Yes.

> The problems are really not simple, the current config language is very
> limited, [...]

I don't think anyone who actually understands the config system would
argue these points, but we are limited by practical constraints to making
incremental improvements only.

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.

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

[John Alvord]

On Thu, 15 Aug 2002 11:52:48 +1000, Greg Banks <gnb@alphalink.com.au>
wrote:

>Roman Zippel wrote:
>> 
>> Hi,
>> 
>> On Tue, 13 Aug 2002, Peter Samuelson wrote:
>> 
>> > Mutating the language, long-term, so that it looks less like sh [...]
>> 
>> That doesn't solve any of the more fundamental problems.
>
>Correct, it doesn't.
>
>> 1) We still have 3 config parsers, which produce slightly different
>> .config files.
>
>Yes.
>
>> 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.
>
>Yes.
>
>> The problems are really not simple, the current config language is very
>> limited, [...]
>
>I don't think anyone who actually understands the config system would
>argue these points, but we are limited by practical constraints to making
>incremental improvements only.

I've been puzzling about this problem and the CML2 trainwreck.

Maybe we can used advanced tools to remove the many bugs and
inconsistancies and then switch to a better config tool. That way the
rulebase will be (almost) identical when the config process changes.

john alvord

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

[Peter Samuelson]

[John Alvord]
> I've been puzzling about this problem and the CML2 trainwreck.
> 
> Maybe we can used advanced tools to remove the many bugs and
> inconsistancies and then switch to a better config tool.

That's exactly what we're trying to do.  Greg has the advanced
consistency checking, and I've been trying to remove ambiguities and
warts in the current rule corpus, and simultaneously come up with some
extensions to the current language that will let us remove *more*
warts.  The extensions are designed to completely supplant certain
existing constructs which I consider ugly and difficult to parse.

To paraphrase Orwell: it was intended that when Newspeak had been
adopted once and for all and Oldspeak forgotten, a buggy parser should
be literally unimplementable, at least so far as implementation is
dependent on clear syntax and reasonable semantics.

Peter

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

[Roman Zippel]

Hi,

(Could you please fix your mailer? linux-m68k.org.com does not really
exist.)

On Thu, 15 Aug 2002, Greg Banks wrote:

> > The problems are really not simple, the current config language is very
> > limited, [...]
>
> I don't think anyone who actually understands the config system would
> argue these points, but we are limited by practical constraints to making
> incremental improvements only.

That's fine with me, but nonetheless I'd really like to know where it will
go to. Just fixing the easy problems is simple, but so far I haven't seen
any plan on how to fix the hard problems. Anyone starting to fix all the
problems should have at least some ideas how to do it and I'd really like
to hear them. I don't want to discourage anyone, but he should understand
the complete problem first before going for the easy targets.

bye, Roman

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

[Kai Germaschewski]

On Thu, 15 Aug 2002, Roman Zippel wrote:

> > I don't think anyone who actually understands the config system would
> > argue these points, but we are limited by practical constraints to making
> > incremental improvements only.
> 
> That's fine with me, but nonetheless I'd really like to know where it will
> go to. Just fixing the easy problems is simple, but so far I haven't seen
> any plan on how to fix the hard problems. Anyone starting to fix all the
> problems should have at least some ideas how to do it and I'd really like
> to hear them. I don't want to discourage anyone, but he should understand
> the complete problem first before going for the easy targets.

I think concentrating on the small gotchas for now is a good thing. 
Surely not all conceptual problems are fixable easily, they probably need 
to be done in conjunction with switching to a common parser etc. (Note: 
this switch to a new parser should happen with no change to the config.in 
format or semantics, in order to fit the Linux/Linus way of doing things). 
However, I think it is too late in 2.5 for these kind of big changes.

That doesn't mean that fixing bugs, of which there are plenty, and small 
improvements like "" == "n" where possible shouldn't be done. If nothing 
else, it will at least give a better starting point for more elaborate 
work later.

--Kai

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

[Roman Zippel]

Hi,

On Thu, 15 Aug 2002, Kai Germaschewski wrote:

> Surely not all conceptual problems are fixable easily, they probably need
> to be done in conjunction with switching to a common parser etc. (Note:
> this switch to a new parser should happen with no change to the config.in
> format or semantics, in order to fit the Linux/Linus way of doing things).

This is where I disagree. Switching the parser and the syntax separately
would mean two big changes, that need to be tested. You actually have to
write two parsers, one that emulates the shell behaviour as exactly as
possible and a second parser that get rids of that again. Doing a single
switch would be far less painful.
There are some corner cases in the current rulebase, which are difficult/
ambiguous for a compiling parser (instead of interpreting). These cases
are mostly in arch/*/config.in files, which were probably never tested
with xconfig.
My converter can convert almost everything, with some small changes to the
input files it should also be able to convert the rest. The resulting
needs some small editing to be completely useable, so this process is not
completely automatic (The reason for this are the recursive dependencies,
which need some small manual fixing).
I tried very hard to make that switch as painless as possible. By
automatically converting the config the rulebase is still almost the same.
Normal users will hardly see a difference (except for xconfig, as that
is reimplemented in QT).

> However, I think it is too late in 2.5 for these kind of big changes.

Most of the work is actually already done, there isn't that much left to
be completely usable. If anyone wants to help, I'd be happy.

bye, Roman

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

[Greg Banks]

Roman Zippel wrote:
> 
> Hi,
> 
> (Could you please fix your mailer? linux-m68k.org.com does not really
> exist.)

I believe the problem is upstream of the machine I control.  I'll see what I can do.

> That's fine with me, but nonetheless I'd really like to know where it will
> go to. Just fixing the easy problems is simple, but so far I haven't seen
> any plan on how to fix the hard problems. Anyone starting to fix all the
> problems should have at least some ideas how to do it and I'd really like
> to hear them. I don't want to discourage anyone, but he should understand
> the complete problem first before going for the easy targets.

The easy targets being done now are mostly things that I believe would need
to be done regardless of the eventual strategy, be it a) do nothing b) make
the existing system suck less c) replace the parsers and keep the rules
d) replace everything.  For any of these strategies to be successful you would
need to start with a clean clear and consistent rules corpus.

Remember how people were complaining that ESR couldn't prove that the CML2
rules corpus did the same things as the CML1 rules corpus?  One of the
reasons was that the CML1 rules corpus is so screwed that's its impossible
for either a human or a machine to figure out what was supposed to happen
and whether what was actually happening was deliberate.  

Roman, I believe the exactly same issue will apply to your config system
too, because it uses a machine translation step from CML1.  GCML2's syntax
checker started life as a CML1-to-CML2 converter (inspired by your work), but
I gave up on machine translating because it would be GIGO.

This is why I'm not talking about replacing shell based parsers yet.  First
we need to get a rules corpus for which it is possible to create a parser
which can parse cleanly, consistently, and correctly.

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.

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

[Roman Zippel]

Hi,

On Fri, 16 Aug 2002, Greg Banks wrote:

> The easy targets being done now are mostly things that I believe would need
> to be done regardless of the eventual strategy, be it a) do nothing b) make
> the existing system suck less c) replace the parsers and keep the rules
> d) replace everything.  For any of these strategies to be successful you would
> need to start with a clean clear and consistent rules corpus.

The problem here is one should consider, how all these little changes will
help to solve the big problems. Do they allow to more easily fix the big
problems or have these changes to be dumped again?
Most of the suggestions I've seen so far fix problems, which either can be
either fixed automatically or which don't exists anymore, once we switch
to a new syntax/parser. That's the reason I ask to understand the whole
picture, so we can judge whether a change is really necessary or not.

> Remember how people were complaining that ESR couldn't prove that the CML2
> rules corpus did the same things as the CML1 rules corpus?  One of the
> reasons was that the CML1 rules corpus is so screwed that's its impossible
> for either a human or a machine to figure out what was supposed to happen
> and whether what was actually happening was deliberate.

I can't give you a mathematical proof, but I tried very hard to keep the
behaviour the same. Unless I made mistake the rules are almost exactly the
same. Most of the CML1 rules are usable, there are only very few cases
which need manual fixing. I can't guarantee that where won't be any
surprises, but they should be easily fixable in the new system. (Unless
ESR I don't insist that my rulebase is correct or perfect, so I'm open to
suggestion/changes. :) )

> This is why I'm not talking about replacing shell based parsers yet.  First
> we need to get a rules corpus for which it is possible to create a parser
> which can parse cleanly, consistently, and correctly.

Most of these problems can actually be fixed without syntax changes.
Something that can't be sanely fixed this way are recursive dependencies,
which I think are not worth fixing with the old parsers, but which are
easily fixable with the new syntax.
If you want to fix logical errors in the rulebase, they will be more
easily fixable with the new tools. For the X interface I'm planning some
debug options, which e.g. allow you to see the complete dependencies of
every symbol.

bye, Roman

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

[Greg Banks]

Roman Zippel wrote:
> 
> The problem here is one should consider, how all these little changes will
> help to solve the big problems. Do they allow to more easily fix the big
> problems or have these changes to be dumped again?

I believe fixing the existing rules within the existing syntax is an exercise
worth doing, and that the results will carry across to whatever extended syntax/
new language/new parsers/whatever will be the long-term solution.

Extending the CML1 syntax now is a fun game but a gamble.

> Most of the suggestions I've seen so far fix problems, which either can be
> either fixed automatically or which don't exists anymore, once we switch
> to a new syntax/parser. That's the reason I ask to understand the whole
> picture, so we can judge whether a change is really necessary or not.

Unlike you, I'm not optimistic that a switch to a new language or even a new
parser for the old language will ever happen.

> I can't give you a mathematical proof, but I tried very hard to keep the
> behaviour the same. Unless I made mistake the rules are almost exactly the
> same. Most of the CML1 rules are usable, there are only very few cases
> which need manual fixing. I can't guarantee that where won't be any
> surprises, but they should be easily fixable in the new system. (Unless
> ESR I don't insist that my rulebase is correct or perfect, so I'm open to
> suggestion/changes. :) )

In  http://marc.theaimsgroup.com/?l=linux-kernel&m=101387128818052&w=2
David Woodhouse gives an idea of what would be necessary to get a new
language+parser accepted.  Can you achieve that yet?

> Most of these problems can actually be fixed without syntax changes.

Yes, a great deal of them can be, and those should be done ASAP.

> Something that can't be sanely fixed this way are recursive dependencies,
> which I think are not worth fixing with the old parsers, but which are
> easily fixable with the new syntax.

Indeed, and those are rare corner cases.

> If you want to fix logical errors in the rulebase, they will be more
> easily fixable with the new tools. For the X interface I'm planning some
> debug options, which e.g. allow you to see the complete dependencies of
> every symbol.

Or you could, today, go build gcml2 from source with "make DEBUG=1" and run

cml-check --debug nodes arch/i386/config.in


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.

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

[Roman Zippel]

Hi,

On Mon, 19 Aug 2002, Greg Banks wrote:

> Unlike you, I'm not optimistic that a switch to a new language or even a new
> parser for the old language will ever happen.

It would be nice if I could get it into 2.6, but it's not a problem if it
has to wait. I'm currently busy getting menuconfig working again and then
I'm pretty much ready for a beta release.

> In  http://marc.theaimsgroup.com/?l=linux-kernel&m=101387128818052&w=2
> David Woodhouse gives an idea of what would be necessary to get a new
> language+parser accepted.  Can you achieve that yet?

If you compare it to the xconfig output, yes.

> Or you could, today, go build gcml2 from source with "make DEBUG=1" and run

I looked through the list and except from real syntax errors nothing
prevents an automatic conversion.
I have to manually fix things like CONFIG_ALPHA_NONAME, which is first set
by a choice statement and later redefined. My new parser can't deal with
this, because user input is given the highest priority.

bye, Roman

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

[Greg Banks]

Roman Zippel wrote:
> 
> I looked through the list and except from real syntax errors nothing
> prevents an automatic conversion.
> I have to manually fix things like CONFIG_ALPHA_NONAME, which is first set
> by a choice statement and later redefined. My new parser can't deal with
> this, because user input is given the highest priority.

Well then, there's something we need to look at fixing in the CML1
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.

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

[Roman Zippel]

Hi,

On Wed, 21 Aug 2002, Greg Banks wrote:

> > I have to manually fix things like CONFIG_ALPHA_NONAME, which is first set
> > by a choice statement and later redefined. My new parser can't deal with
> > this, because user input is given the highest priority.
>
> Well then, there's something we need to look at fixing in the CML1
> corpus.

I considered detecting such cases, but it's too much work for something
that is easy to find and fix manually. The alpha config.in is actually the
only config file I could find that does something like this.

bye, Roman

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

[Sam Ravnborg]

On Mon, Aug 19, 2002 at 07:27:50PM +1000, Greg Banks wrote:
> I'm not optimistic that a switch to a new language or even a new
> parser for the old language will ever happen.
I asked Linus specifically about the replacement of the shell based parsers.
The answer were quite simple:
- It should be convinient to use a new parser.
	- Fast compilation, no errors etc.
It's doable.

> In  http://marc.theaimsgroup.com/?l=linux-kernel&m=101387128818052&w=2
> David Woodhouse gives an idea of what would be necessary to get a new
> language+parser accepted.  Can you achieve that yet?
David suggest to use randomly generated configurations, but they lack
one important feature. They are always valid, and a new system shall be
able to deal with hand-edited .config files in the same way as oldconfig.

	Sam

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

[David Woodhouse]

sam@ravnborg.org said:
> David suggest to use randomly generated configurations, but they lack
> one important feature. They are always valid, and a new system shall
> be able to deal with hand-edited .config files in the same way as
> oldconfig. 

I suggested those as a way for testing the equivalence of the old and new
rulesets if the language changed. My main objection to CML2 was not the
language itself or the gratuitous use of python, but the fact that the
actual configuration rules were changed in extremely dubious ways.

Think 'provably correct transforms between AndreCode and C'.

You do also want to deal with hand-edited .config files in a similar manner 
to the existing tools, yes -- but that's a different issue.

--
dwmw2

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

[Kai Germaschewski]

On Mon, 19 Aug 2002, Greg Banks wrote:

> Roman Zippel wrote:
> > 
> > The problem here is one should consider, how all these little changes will
> > help to solve the big problems. Do they allow to more easily fix the big
> > problems or have these changes to be dumped again?
> 
> I believe fixing the existing rules within the existing syntax is an exercise
> worth doing, and that the results will carry across to whatever extended syntax/
> new language/new parsers/whatever will be the long-term solution.

Let me just second this. This doesn't mean to try random changes hoping 
that in the end the result is something sensible. But there are many cases 
which are obviously bugs or deficiences, and fixes / cleanups there are 
definitely a good idea as a first step.

--Kai

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

[Roman Zippel]

Hi,

On Fri, 23 Aug 2002, Kai Germaschewski wrote:

> > I believe fixing the existing rules within the existing syntax is an exercise
> > worth doing, and that the results will carry across to whatever extended syntax/
> > new language/new parsers/whatever will be the long-term solution.
>
> Let me just second this. This doesn't mean to try random changes hoping
> that in the end the result is something sensible. But there are many cases
> which are obviously bugs or deficiences, and fixes / cleanups there are
> definitely a good idea as a first step.

Let me mention (again), that we are talking about two different problems
here. On the hand bugs in the rulebase can be fixed with either syntax. On
the other hand major cleanups/extensions are better done with only a
single parser.

bye, Roman

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

[Greg Banks]

Roman Zippel wrote:
> 
> Let me mention (again), that we are talking about two different problems
> here. On the hand bugs in the rulebase can be fixed with either syntax.

Agreed.

> On
> the other hand major cleanups/extensions are better done with only a
> single parser.

>From a purely technical point of view it's easier to extend a single parser
than N.  A single parser is the Obviously Correct Approach (tm).

But the problem is that changing to use a single parser is in itself
a revolutionary step, doubly so if the syntax changes at the same time.

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.

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

[Greg Banks]

Kai Germaschewski wrote:
> 
> > > 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.

Great.

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

Ah, interesting idea.

> Anyway, some more points:
> 
> o a) dep_bool '  Blah' CONFIG_FOO $CONFIG_BAR         vs.
>   b) dep_bool '  Blah' CONFIG_FOO CONFIG_BAR

I assume you include in a) the change which gives all symbols an "n" default.
Then b) is clearly the evolutionary approach and less likely to result in a
partially broken config system come Halloween.

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.

Re: [patch] config language dep_* enhancements

[Peter Samuelson]

  [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

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

[Greg Banks]

Peter Samuelson wrote:
> 
> >
> >    [...]CONFIG_BLK_DEV_IDESCSI[...]
> >
> 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..

Ah, good.

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

Actually I have got the desire to fix them, what I lack is the ability
to get patches into the kernel that are too non-trivial to go through Rusty.

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

Ok, but perhaps it's not clear how many problems there are.  The full
log file from a gcml2 run on 2.5.29 is 573 KiB.  Here's a summary:

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
5      spurious-dependencies
187    nonliteral-define
28     unset-statement		(ignore these)
25     different-banner
61     different-parent
36     overlapping-definitions
1      primitive-in-root
310    undeclared-symbol
73     forward-compared-to-n
287    forward-reference
1093   forward-dependancy
1      symbol-like-literal
103    constant-symbol-dependency
8      different-compound-type
3562   total

These numbers are aggregates over 17 arches, so you need to divide by
a number between 1 and 17.  Also some of these have been fixed in 2.5.30.
I can post the full list if people want, but it would be a bit overwhelming.

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

Ok then.

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

I'm not able to detect anything like that.

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

Actually config language isn't really procedural, pseudo-procedural would
be more like it.

> I *really* don't want to go *there*, though. (:

Yep.

> > And "" != "n" in other contexts, like if [];then statements.
> 
> That is true.  But that should not affect the dep_* logic, should it?

Correct, I'm just pointing out that using orthogonality arguments with
the config language is not going to get you anywhere useful.

> The point here is that people who aren't hip-deep in config language
> code don't think about them being separate.  Ergo bugs.

Agreed.

> I've been thinking hard about a new sort of 'if' statement that
> doesn't look like a test command.  

Interesting, I'd like to hear more.

My favourite idea is a different form of choice which worked more
like a menu, so you could intersperse conditionals with the choice
items.  This would help with the several places in CML1 were the
same choice is mostly-duplicated in different conditionals, e.g.
'Kernel page size' in arch/ia64/config.in.  ESR worked out a sensible
set of semantics for how this should work.

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

Sounds good to me.

> This is if we don't end up
> adopting a whole new language like CML2 or Roman's stuff.)

Or a new parser & frontends for the existing language.

I'm not convinced that a complete new language will ever succeed after
the CML2 debacle, machine translated or not.  This is why I gave up the
idea of automatically converting CML1 to CML2.

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.

Re: [patch] config language dep_* enhancements

[Sam Ravnborg]

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?

	Sam

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

[Peter Samuelson]

[Sam Ravnborg]
> How about extending the language (side effect) to automagically
> append (EXPERIMENTAL) or (OBSOLETE) to the menu line, if dependent
> on those special tags?

I've thought about that too.  Menuconfig already has magic code to
append ' (NEW)' if it hasn't seen a symbol before.

Your proposed change, however, cannot be easily parsed until we make
'$' optional (and deprecated) in dep_* tags.  The existing Configure
and Menuconfig borrow the /bin/sh parser which, if allowed to see
"$CONFIG_EXPERIMENTAL", will expand it too early to be of use.

Peter

Re: [patch] config language dep_* enhancements

[Greg Banks]

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.

Get rid of shell based Config.in parsers?

[Sam Ravnborg]

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

Re: [kbuild-devel] Get rid of shell based Config.in parsers?

[Peter Samuelson]

[Sam Ravnborg]
> Where comes the requirement that we shall keep the existing shell 
> based config parsers?

I don't make that argument - mconfig is the superior solution by far -
but it is certainly the path of least resistance.

As pertains to CONFIG_EXPERIMENTAL and " (EXPERIMENTAL)", it *is*
possible to add such a feature to the shell-based parsers by changing
the syntax slightly - specifically to lose the '$' on dependencies.

Changing the syntax *does* have ramifications when it means adapting
three separate parsers, but it can be done.

> 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 would have been a big change and a big flag day, and among other
problems, the rulebase conversion issue was handled wrong.  Eric
refused to start from a 1-1 equivalent rulebase, preferring to tweak
the rulebase as he went along - partly just to fix bugs, partly to
show off his new capabilities.  Unfortunately, without the
apples-to-apples comparison, many people distrusted the new system,
superior though it was in many ways.

This is the primary lesson to be learned from CML2.  Anyone trying to
redesign a subsystem such as the kernel config system needs to keep it
in mind.  (Yes, I know from the rest of your message that you learned
it.)

Peter

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

[Linus Torvalds]

On Wed, 14 Aug 2002, Sam Ravnborg wrote:
> 
> Where comes the requirement that we shall keep the existing shell 
> based config parsers?

I use them exclusively.

It is far and away the most convenient parsing - just to do "make
oldconfig"  (possibly by making changes by hand to the .config file
first).

As far as I'm personally concerned, the shell parsers are the _only_ 
parser that really matter. So if you want to replace them with something 
else, that something else had better be pretty much perfect and not take 
all that long to build.

		Linus

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

[Thunder from the hill]

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

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

[Roman Zippel]

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

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

[Andi Kleen]

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

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

[Roman Zippel]

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

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

[Peter Samuelson]

  [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

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

[Roman Zippel]

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

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

[Peter Samuelson]

  [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

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

[Russell King]

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

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

[Peter Samuelson]

[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

Re: [kbuild-devel] Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

[Greg Banks]

Peter Samuelson wrote:
> 
> [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.

So what is !"" ?

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.

Re: [kbuild-devel] Re: 64bit clean drivers was Re: Linux 2.4.20-pre1

[Thunder from the hill]

Hi,

On Sat, 10 Aug 2002, Greg Banks wrote:
> So what is !"" ?

Ought to be y.

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

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

[Andi Kleen]

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

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

[Roman Zippel]

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

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

[Thunder from the hill]

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