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

RE: Linux 2.4.20-pre1

[Matt_Domsch]

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

I've submitted patches to David Mosberger against 2.4 and 2.5 BK current,
and the latest 2.4 ia64 port patch, which moves efi.h from include/asm-ia64
into include/linux.  This is important now that the GUID Partition Table
(GPT) code is included in the stock 2.4 and 2.5 kernels, and can be used on
non-IA64 platforms - specifically for handling really large disks.  There is
no ia64-specific code in efi.h.  David agrees that it's proper to make this
change.
 
I've asked David, as IA64 port maintainer who currently "owns" this file, to
forward these to Alan, Marcelo, DaveJ, and Linus respectively.

For the curious, the posts to linux-ia64 with patches and explanations:

For 2.5 BK-current:
https://external-lists.vasoftware.com/archives//linux-ia64/2002-August/00385
1.html
https://external-lists.vasoftware.com/archives//linux-ia64/2002-August/00385
2.html

For 2.4 BK-current and ia64-current:
https://external-lists.vasoftware.com/archives//linux-ia64/2002-August/00385
3.html


Thanks,
Matt

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

RE: Linux 2.4.20-pre1

[Matt_Domsch]

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

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

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


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

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

Thanks,
Matt

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

Linux 2.4.20-pre1

[Alan Cox]

[+ indicates stuff that went to Marcelo, o stuff that has not,
 * indicates stuff that is merged in mainstream now, X stuff that proved
   bad and was dropped out, - indicates stuff not relevant to the main tree]

The HP merge is now down to 3937 lines pending

Current IDE mysteries to fix
-	Hang on at least one VIA/HPT combo
-	Still one report of a promise hang
-	IDE failure specific to Fujitsu laptop

Remaining IDE non mysteries to fix
-	No DMA on OSB4 IDE

Remaining IDE to check
-	Does Ali rev 0xC4 support LBA48, or is it > C4 that does


Linux 2.4.20-pre1-ac1
o	Merge with 2.4.20pre1
	- Drop broken isicom change
	- Fix formatting errors in x86_64 char/Config.in
	- Fix formatting errors in x86_64 isdn/Config.in
	- Fix formatting errors in x86_64  radio card Config.in
	- Fix formatting errors in x86_64 drivers/net/Config.in
	- Drop broken atarilance change
	- Fix wrong ioctl return in e100_ethtool_test, e100_ethtool_gstrings
	- Fix security hole in e100 ioctl handler
	- Fix identical hole in e1000 ioctl handler
	- 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
	- Drop utterly bogus change todrivers/sound/Config.in
	- Revert uncompilable tg3 driver
o	Fix up the eepro100 mess from 20pre1		(Jeff Garzik)
o	Switch to Namesys __FUNCTION__ reiserfs fixes	(Oleg Drokin)
o	Fix eepro formatting on register
o	Fix radeon build on PPC				(Ben Herrenschmidt)
o	PPC scheduler, bitups, rwsem bits		(Ben Herrenschmidt)
o	Rework JFS indoe locking			(David Kleikamp)
o	Dynamically allocate JFS metapages		(David Kleikamp)
o	JFS rmdir/unlink d_delete removal		(David Kleikamp)
o	Add resize support to JFS			(David Kleikamp)
o	Rmemove unused code in aacraid			(Christoph Hellwig)
o	Export the new pci_enable function to modules	(Tomas Szepe)
o	Handle APM on armada laptops			(Samuel Thibault)
o	Fix further errors in depca
o	Fix a harmless physical/logical cpu confusion	(me)
	in the APM code
-	Fix migration to CPU 0 before poweroff		(me)
o	Make the APM on CPU 0 locking cover all of APM	(me)
	| idle on SMP needs work, but this seems to work for the rest
	| with my SMP boxes

Linux 2.4.19-ac4
o	Fix pci_enable_device bug I added in ac3	(Jeremy Fitzhardinge)
o	Don't program the ALi ISA bits when using a	(Go Taniguchi, 
	Non ALi Northbridge				 Bruce Howards, me)
*	E1000 Gigabit ethernet driver
o	Fix build for I/O debug MULTIQUAD I hope	(me)
	| Found by Willy Tarreau
*	Bluetooth core update/hot plug support		(Maksim Krasnyanskiy)
*	L2CAP lock fixes, datagram and shutdown		(Maksim Krasnyanskiy)
*	Fix locking in SCO bluetooth layer		(Maksim Krasnyanskiy)
*	Update hci_usb driver, fix refcounting		(Maksim Krasnyanskiy)
*	Add BNEP support to bluetooth			(Maksim Krasnyanskiy)
o	Fix iee1394 build failure			(me)
o	Fix BUZ_G_STATUS in zr36067			(me)
o	Fix warning in fdomain.c			(me)
o	Fix warning in pas16 driver			(me)
o	Fix warning in bin2hex.c			(me)
o	Fix warning in xirc2ps_cs			(me)

Linux 2.4.19-ac3
o	Rethink number one on the IDE stuff		(me)
	We go back to the old pci setup, and
	add the ability to enable devices with
	some BAR's left unassigned

Linux 2.4.19-ac2
o	Disable LBA48 on ALi IDE			(Andre Hedrick,
	revisions below 0xC4				 Daniela Engert)
o	Fix __FUNCTION__ warnings in reiserfs		(me)
*	Fix __FUNCTION__ in rest of irda drivers	(me)
o	Fix __FUNCTION__ in some more net/irda bits	(me)
o	Add sem_getcount abstraction from parisc tree
o	Merge some of the minor pcnet32 changes from
	the parisc tree
o	Fix __FUNCTION__ in the ldm partition code	(me)
o	Fix __FUNCTION__ in cycx_wan driver		(me)
X	Add full IDE reassignment based on description	(me)
	from Petr Vandrovec
o	Update defconfig for the -ac tree		(Niels Jensen)
*	Fix AGP warnings				(Niels Jensen)
o	Make rwlock_t not waste space on gcc 2.95/2.96	(Niels Jensen)

Linux 2.4.19-ac1
o	Merge with 2.4.19
o	Add identifiers for the 3Com AirConnect PCI	(Ingo Rohifs)
*	Fix typo in sym2 comments			(Grant Grundler)
*	Fix cyclades resource bug			(Florian Lohoff)
o	Fix address reporting on segv and friends for	(Aneesh Kumar)
	Alpha
o	Merge APM fixes for crashes on ASUS board	(Willy Tarreau)
o	Add module tags to toshiba smm driver		(Jonathan Buzzard)
*	Fix extern for init_rootfs			(Christoph Hellwig)
*	Make vmalloc.h include highmem.h to fix 	(Keith Owens)
	build errors on some setups
o	More __FUNCTION__ clean up for gcc 3.1		(me)

Linux 2.4.19rc5-ac1
o	Merge with 2.4.19rc5
o	Flush the right thing in ramdisk		(HP merge)
o	Merge further small hppa bits			(HP merge)
o	Fix ide option breakage				(Mikael Petterson)
o	Fix a JFFS2 oops case				(David Woodhouse)
o	Switch 'processor id' to 'physical id'		(me)
	| Keeps glibc happy until we sort out cpu numbers longer term
o	Fix incorrect marking of phys_proc_id init	(David Luyer)
o	Update the experimental amd76x_pm code		(Johnathan Hicks)
*	EEPro10 update				(Aristeu Sergio Rozanski Filho)
o	Fix missing prototype				(Christoph Hellwig)
o	Make mount hash size more sensible		(Christoph Hellwig)
o	Make i386 semaphore implementation gcc3 safe	(Christoph Hellwig)
o	Remove dead code in alim15x3 IDE code		(me)
o	Make the i8x0 audio power up more conservative	(me)
o	Enable EAPD on i8x0 audio devices		(me)
	| Hopefully this will fix some of the 'silent laptop' problems
*	Fix misordering in drivers/net/Config		(Willy Tarreau)
*	Fix undefined C usage in ixj			(me)
*	Fix undefined C usage in se401			(me)
o	Kill __FUNCTION__ in some usb drivers		(me)

Linux 2.4.19rc3-ac5
o	Fix the SMP compile problem			(me)
	| Better solutions preferred - suggestions anyone ?
o/*	Exterminate more of the __FUNCTION__ warnings	(me)
*	Fix warning in stallion and real loading bug	(me)
o/*	Fix various random gcc 3.1 warnings		(me)
o	Hopefully fix the DRM compile for gcc 2.95	(me)
*	Tighten multiple length checks in intermezzo	(Silvio Cesare, me)
*	Fix upper limit on stradis cliprects		(Silvio Cesare, me)
*	Fix proc_file_lseek				(me)
*	Fix drivers/s390/dasd write limit		(Silvio Cesare, me)
*	Fix ewrk3 and natsemi driver lengthchecks	(Silvio Cesare, me)
*	Openprom fixes					(Dave Miller)
*	Network procfs fixes				(Dave Miller)
o	Fix a couple of license tags			(Carl-Daniel Hailfinger)
o	Don't pad empty initializers with gcc 2.95+	(Christoph Hellwig)
o	Make better use of dentry inline space		(Andi Kleen)
o	Fix ffs asm for gcc 3.x				(Christoph Hellwig)
o	Remove last gcc3 warnings on ext3		(Christoph Hellwig)
o	Warn when mounting ext3 as ext2			(Andrew Morton)
*	Make umem useadd_gendisk			(Christoph Hellwig)
o	Fix cpqarray I/O accountinmg			(Christoph Hellwig)
*	Fix for TCSBRK standards compliance
	| LSB patch with further bugs fixed
*	Fix lots more __FUNCTION__ stuff		(me)
*	Fix warnings in hamradio drivers with gcc3	(me)

Linux 2.4.19rc3-ac4
o	Support "help" button Vaio PCG-NV105		(Frank Schusdziarra)
*	Clear AC on int in vm86 emulation		(Stas Sergeev)
*	Clean up stack handling macros in vm86		(Stas Sergeev)
*	Handle multiple prefixes on vm86 traps		(Stas Sergeev)
o	Use FIXMAP for f00f fixups			(Andrea Arcangeli,
							 Christoph Hellwig)
o	Cacheline align tlb state			(Andrea Arcangeli)
o	cmpxchg8 needs lock prefix			(Andrea Arcangeli)
o	Make O1 scheduler hyperthreading aware		(Intel)
	| Plus some cleanup, performance fix
o	make xconfig fix up				(Pete Zaitcev)
o	Fix a misidentification of Tualatin		(Dave Jones)
o	Update SiS IDE driver for ATA133		(Lui-Chen Chang,
							 Lionel Bouton)
o	Update procfs for inode sysctl changes		(James Antill)
o	Final fixups for summit support			(James Cleverdon)
*	Fix missing sign check in se401 driver		(Silvio Cesare)
*	Fix missing wrap check in usbvideo		(Silvio Cesare)
o	Fix netsyms includes				(Martin Uecker)
o	Penguin logo frame buffer fix			(Geert Uytterhoeven)
o	sym53c8xx_2 fixes for bugs tickled on hppa	(Grant Grundler)
o	Remove vm_unacct_vma				(Hugh Dickins)
o	Handle do_mmap_pgoff mask properly		(Hugh Dickins)
o	Update to rmap-13b				(Rik van Riel,
						Arjan van de Ven, Hugh Dickins)
*	Fix trident audio suspend/resume crash		(Muli Ben-Yehuda)
o	Give panic info in morse code on graphic oops	(Andrew Rodland)
o	Add a new kaweth usb ident			(Harm Verhagen)
o	Fix warnings from init_task.c			(Alex Riesen)
o	IRQ balancing fix backport from 2.5		(Zwane Mwaikambo)
o	Clean up LDM support				(Richard Russon)
*	Fix lib/rbtree mismerge				(Christoph Hellwig)
*	Endian fixes for 8390 drivers			(from HPPA merge)
o	Support tulip on the parisc platform		(from HPPA merge)
*	Update parport_gsc				(Helge Deller)
o	Merge fault handling changes for upward		(from HPPA merge)
	growing stacks
o	Fix undefined C in speakup			(me)
*	Fix umem undefined C				(me)
*	Fix a few other warnings			(me)
*	Lots of gcc 3.1 __FUNCTION__ warning fixes	(me)

Linux 2.4.19rc3-ac3
o	Hopefully fix the smp boot/apic problem		(James Cleverdon)
o	Tidy various VM bits up				(Christoph Hellwig)
o	Further quota updates		(Jan Kara, Al Viro, Christoph Hellwig)
*	Fix incorrect tristate in Config.in		(Keith Owens)
o	amd76x_pm compile fix				(Erik Andersen)
 
Linux 2.4.19rc3-ac2
o	Fix escaped iconfig makefile line		(Greg Louis)
*	Fix a dcache locking error			(Al Viro)
o	AMD native powermanagement			(Tony Lindgren,
							 Johnathan Hicks)
	| Replaces amd768_pm as its already far better
-	Remove dead tq_bdflush				(Christoph Hellwig)
-	Remove dead pg_nosave bits			(Christoph Hellwig)
-	Remove dead 8253x build script			(Christoph Hellwig)
o	Clean up speakup Makefile			(Christoph Hellwig)
o	Fix typo in drivers/net/Config.in		(Hans-Joachim Baader)
o	Update to new quota code with dual format	(Jan Kara)
	support
o	Add the XFS framework for quota into it		(Nathan Scott)
*	Fix unaligned access on ewrk3			(Martin Brulisauer)
o	Fix config breakage from mips merge		(Christoph Hellwig)
*	Recognize GPLv2 as a valid license		(Keith Owens)
o	Update ACPI hotplug driver			(Takayoshi KOCHI)
	| And fix posted shortly after
o	Remove ksyms.c debugging junk			(Khromy)
o	Remove limits.h use in speakup			(Adrian Bunk)
o	NFS lock daemon fixes				(Olaf Kirch)
	| Sign errors, Openserver interoperability
*	Further trident sound cleanup and fixes		(Muli Ben-Yehuda)
o	Change tcp_diag.h fix to keep DaveM happy	(me)
o	Add via apic to expected apic versions		(me)
o	Next batch of summit tweaks			(James Cleverdon)
	| Won't fix the existing APIC problem
o	Add Vaio C1MV mode lines to radeonfb		(James Mayer)
*	Fix sloppy sign handling in apm and rio500	(Silvio Cesare)
*	Reformat depca.c ready for some bugfixes	(me)

Linux 2.4.19rc3-a1
o	Merge with 2.4.19rc3

Linux 2.4.19rc2-ac2
o	Fix ide probe crash stupid bug in ac1		(me)
	| I mismerged Kurt's change

Linux 2.4.19rc2-ac1
o	Merge with 2.4.19-rc2
*	Minor HP merge fixup
o	Orinoco build fix				(Adrian Bunk)
o	Vaio C1VE/N frame buffer console mode		(Marcel Wijlaars)
o	Fix an inverted test in sym53c8xx_2		(Grant Grundler)
o	Fix aic7xxx build without PCI enabled		(me)
o	Clear allocated gendisk in IDE			(Kurt Garloff)

Linux 2.4.19rc1-ac7
*	Merge more HPPA bits
X	tcp_diag alignment fixup			(Richard Henderson)
	| Pending DaveM making a nicer fix Im sure
o	Hopefully fix the SMP APIC problems rc6		(James Cleverdon)
	gave some people
o	Fix incorrect __init in PCI core		(Takayoshi KOCHI)
	| Caused hotplug bugs
o	Update IBM PCI hotplug driver			(Greg Kroah-Hartmann)
*	Add SCSI blacklist entries for Centristor	(Robert Sertic)
o	Update Documentation/sysctl/vm.txt		(Steven Cole)
*	Fix kdev_val macro				(Steven Cole)
o	Allow a user to force dma 0 to be allowed	(Gerald Teschl)
	for ISAPnP [be nice to autodetect this ?]
o	Hopefully fix bogus config question bug		(me)
*	Fix hang on some boxes if you unload
	maestro audio then hit the volume buttons	(Samuel Thibault)
*	Fix aha152x scsi				(Juergen Fischer)
o	Bluetooth pcmcia drivers			(Marcel Holtmann)

Linux 2.4.19rc1-ac6
o	Update merge using bits from newer summit diff	(James Cleverdon)
o	Fix problems with non SMP but io-apic build	(me)
o	Socket error path memory leak fix		(Robert Love)
o	Fix sd_varyio masks for higher drives		(Kurt Garloff)
o	Fix tmpfs double kunmap				(Hugh Dickins)
o	VIA rhine cleanup/fixes				(Roger Luethi)
o	Fix typos in ncr/seagate scsi			(James Mayer)
*	MPT fusion update				(Pam Delaney)
*	Trident audio code cleanups and lock fixes	(Muli Ben-Yehuda)
o	Fix irq balancing for summit boxes with Ingo's	(James Cleverdon)
	PIV balancer

Linux 2.4.19rc1-ac5
o	Add additional promise chip names provided by	(me)
	Hank Yang
o	Fix promise 20277 misreporting			(me)
o	Remove extra argument from vm_enough_memory	(me)
	| Suggested by Hugh Dickins
*/+	Initial merge of main chunk of parisc-55 tree
	- fix scheduling of disabled kbd tasklet

Linux 2.4.19rc1-ac4
o	Tweak pnpbios permissions on escd file		(me)
	| We only want root able to see it
o	Merge first bits of Summit stuff		(me)
	| Working from ugly ibm patch for 2.4.9
o	Fix casting warnings in i830 DRM		(me)
*	Fix atp870u warning				(me)
o	Fix APM hang on resume with SMP kernel on up	(me)
	laptop
o	Change added proc/cpuinfo entries to fit format(me)
o	Fix PIV clockmod				(Peter Osterlund)
o	Re-order scsi disk structure to save space	(Kurt Garloff)
o	Fix CPU_FREQ build problem			(Peter Osterlund)
o	Clean up speakup_acntpc			(Arnaldo Carvalho de Melo)
o	Clean up speakup_acntsa			(Arnaldo Carvalho de Melo)
o	Clean up speakup_apolo			(Arnaldo Carvalho de Melo)
o	Basic speakup core cleanups		(Arnaldo Carvalho de Melo)
o	Fix a mishandling of PCIBIOS boxes that	do not	(Mark Lisher)
	use CONF1/CONF2
o	Fix promise skip for new supertrak		(Jan Schmidt)
o	Allocate nocache ram based on mem size for	(Tomas Szepe)
	sparc32
o	Fix incorrect zlib includes			(David Woodhouse)
o	Fix duplicated scsi host idents			(Itai Nahshon)
o	Update ALi5451 audio				(Lei Hu)
	| Sorry this took so long - it got lost
o	Handle radeon cards that report zero RAM	(James Mayer)
o	Blacklist H.01.09 megaraid firmware		(Jan Koop)
o	Initial ALi5455 audio support			(Lei Hu)

Linux 2.4.19rc1-ac3
*	Remove SWSUSPEND
	| With the IDE backport option and other general 2.5 improvements
	| its now best worked on in 2.5
*	Remove duplicate config options			(Steven Cole)	
o	Newer SX6000 has PDC20276 chips. Handle this	(me)
o	Don't use LBA48 hack on Promise 20262/3		(Hank Yang)
*	Switch to Promise namings for chips		(Hank Yang)
*	Update promise drive quirks			(Hank Yang)
o	Fix missing sem up on error in usb printer	(Oliver Neukum)
*	Correct FPU stack fault signal flag bits	(Dave Richards)
o	Resync with base JFS tree			(Dave Kleikamp)
o	Make it clear CMD64x drives CMD680		(Adrian Bunk)

Linux 2.4.19rc1-ac2
*	Update eata and u14/34f drivers			(Dario Ballabio)
o	Handle 3c556 transmitter enable bit		(Andrew Morton)
o	Make the DRM layer use the pci mapping api	(Arjan van de Ven)
o	Set pci dma masks on the i2o devices		(Frank Davis)
*	JFFS2 bug fixes					(Dave Woodhouse)
*	Fix i815 APSIZE masking				(Nicolas Aspert)
o	Remove junk pcxxdelay function			(Sergey Kononenko)
*	EFI partition updates				(Matt Domsch)
	- I took out the MSDOS check - if both are
	  present we should favour MSDOS for now
*	Fix ipc/shm locking				(Hugh Dickins)
*	Update Configure.help				(Steven Cole)
o	USB updates - cleanups				(Greg Kroah-Hartmann)
o	USB fix for intuos tablet			(Christer Nilsson)
o	USB scanner updates		(David Nelson, Henning Meier-Geinitz, 
					 Sergey Vlasov, Karl Heinz Kremer)
	| Note - new maintainer for USB scanner - Brian Beattie
o	Re-merge the ramfs limits code			(David Gibson)
	| * This needs good testing
	| + TODO - make ramfs homour vm_accounting
o	eepro100 warning fix				(Pavel Machek)
o	Report ok for nfs directory fsync       	(Trond Myklebust)
*	Promise 20268 raid should be called 20270	(Hank Yang)
	| Trivial item pulled out of the pending promise patches
o	Speakup HZ != 100 cleanup part 1		(Arjan van de Ven)
o	Report HT info in /proc/cpuinfo			(Arjan van de Ven)
o	PIV IRQ balancing fix				(Ingo Molnar)
o	Allow a non PGE PII optimised build		(Arjan van de Ven)
o	Elevator performance fixes			(Andrea Arcangeli)
o	Update cpufreq, add PIV throttling		(Robert Schwebel,
			Padraig Brady, Zwane Mwaikambo, Arjan van de Ven,
			Tora Engstad)
o	O(1) scheduler updates				(Ingo Molnar)
*	Fix 64bit random panic with 
	"I refuse to corrupt memory/swap"		(Bill Nottingham)
*	Fix compile with floppy disabled		(Adrian Bunk)
*	Quirk handler for Dunord I-3000	  (Dave Close, David Mosberger)
	| Plus I added real PCI idents for neatness
o	Fix another vm accounting corner case		(Robert Love)
o	Patch up XFree 4.1 back compat problems		(Arjan van de Ven)
	in DRM 4.2+

Linux 2.4.19rc1-ac1
o	Merge with 2.4.19-rc1
	- Drop out mm fixes
*	Shmem fixes for -ac 				(Hugh Dickins)
o	Fix vm accounting corner cases			(Hugh Dickins)
*	Fix utimes permission check error		(Stephen Rothwell)
	| It was overstrong
o	Fix JFS error handling down_write_trylock	(David Kleikamp)
o	Module loader off by 1 fix			(Peter Oberparleiter)
o	Allow irda modem bits to be arch set		(Grant Grundler)
*	ALI M1671 GART support				(Arjan van de Ven)
o	IDE scsi off by one transformation fix		(Mark Lord)
o	Printk fixes
o	USBserial semaphore fix				(Pete Zaitcev)
o	Alpha updates for O(1) scheduler		(Robert Love)

Linux 2.4.19pre10-ac2
o	Merge speakup support for blind users
o	CSB6 cable detect for Dell			(Matt Domsch)
o	Update pci ids for Intel i8xx			(Wim Van Sebroeck)
*	Add AMD766 PCI irq router support		(Wayne Whitney)
*	ACARD scsi update				(Matthew Chang)
*	Fix idle-period bug in APM parser		(Laurent Latil)
*	Printk levels for 3c501 ethernet		(Felipe Damasio)
o	AMD768 TCO watchdog driver - * needs testing *	(Zwane Mwaikambo)
*	Fix IDE port offset for pdc202xx		(Hang Yang)
	| should fix LBA48 drives on primary channel
o	Fix incorrect speedstep multiplier detect	(Dominik Brodowski)
*	Add support for Aptiva with Bose subwoofer	(Toshio Spoor, 
							 John Rood)
*	Autodetect SiS 745 AGP 				(Carsten Rietzschel)
*	More scsi sparselun entries			(Arjan van de Ven)
*	Fix possible crash on shutdown with AF_ROSE	(Jean-Paul Roubelat)
*	Intel 845G IDE support				(Andre Hedrick)
o	Further CPiA driver updates			(Duncan Haldane)
o	Fix DAC960 diff that went astray		(Juan Quintela)
o	Add HP arrays to the sparselun list		(Andrew Patterson)

Linux 2.4.19pre10-ac1
o	Merge with Linux 2.4.19-pre10

Linux 2.4.19pre9-ac3
o	Cpufreq updates			(Dominik Brodowski, Dave Jones0
	| Now includes some reverse engineered speedstep support 
o	JFS updates			(David Kleikamp, Christoph Hellwig)
o	CPiA updates/Intel microscope support		(Duncan Haldane)
*	Fix vm86 locking errors on SMP			(Ben LaHaise)
*	Remove dead vm86mode field			(Ben LaHaise)
*	Fix make clean for cl2llc			(Keith Owens)
o	Fix loop errors with highmem			(Ben LaHaise)
*	Fix ipc/sem.c SuS/LSB compliance		(Christopher Yeoh)
X	Update swsuspend maintainer info		(Pavel Machek)
*	Add another drive quirk for the promise		(Hank Yang)
	drivers
o	Merge external journal support for jfs		(David Kleikamp)
o	Add documentation about O(1) scheduler		(Robert Love)
o	O(1) scheduler tidy ups				(Robert Love)
o	Fix remaining extern inline users		(Christoph Hellwig)
o	Cache alignment cleanups for SMP apic timers	(Ravikiran Thirumalai)
o	Ext3 file system updates			(Stephen Tweedie)
o	Fix 'dump corrupts live fs bug'			(Stephen Tweedie)
o	Add DAC960 devices to init table		(Oliver Pitzeier)
	| Lilo doesn't care but grub does ..

Linux 2.4.19pre9-ac2
*	Clean up after SIGURG properly			(David Weinehall)
	| Needed to match the other SuS compliance fix for it
*	Fixed wrong elf section in neofb		(Thomas Mirlacher,
							 Andrey Panin)
*	Don't write to reserved bits on 815 gart	(Nicolas Aspert)
*	Make fcntl locking POSIX 2001 compliant		(Andries Brouwer)
*	Fix an mmap corner case 			(Raúl)
*	Merge 3c59x vlan support			(Paul Komkoff)
*	Update URLS for LDP documentation		(John Kacur)
*	Fix rmem setting for low memory			(J A Magallon)
*	Reparent scsi error thread to init		(J A Magallon)
*	Backport FPU init fixes				(J A Magallon)
*	Fix AGPgart crash on I830M/I845G when using
	8Mb/8Mb split					(Jeff Hartmann)
*	Fix phy masking on 8139too			(Jeff Garzik)
*	Fix link state reporting on generic phy code	(Jeff Garzik)
*	Tulip phy handling fix				(Jeff Garzik)
*	Update 8139too docs				(Jeff Garzik)
*	cs89x0 update					(Jeff Garzik)
*	VIA rhine fixes					(Jeff Garzik)
*	Hamachi quick fixup for 2.4.19			(Keith Underwood)
*	Revert escaped procfs debug code		(Todd Eigenschink)
*	Merge the 2.5 additions to ethtool		(Jeff Garzik)
*	Update dl2k driver				(Jeff Garzik)
*	Fix kernel api docs to reflect fb changes	(Juan Quintela)
*	Fix problems with pcnet32 workaround for x250	(Go Taniguchi)
*	De4x5 cleanups					(Jeff Garzik)


Linux 2.4.19pre9-ac1
o	Merge with 2.4.19pre9
*	Fix SuS violation on readv/writev		(me)
	| I believe this one is correct, please double check

Linux 2.4.19pre8-ac5
*	Fix various audio copy*user			(Rusty Russell)
o	Update to rmap 13		(Rik van Riel, Christoph Hellwig)
*	Fix joystick copy_user bugs			(Robert Johnson)
*	Document the i2o_pci module			(me)
*	Switch i2o_block back to direct pointers	(me)
	to avoid promise firmware bugs
*	Remove cache error paths from i2o_block		(me)
	| new code doesnt trip that bug
*	Reduce the i2o queue depth per device		(me)
	| pending tuning - might need more yet
*	Set i2o default limit at 48K a write		(me)
	| more firmware bug stuff
*	Clean up i2o cache strategy, add tuning ioctl	(me)
*	Allow users to force dpt cards to use base i2o	(me)
	| tested i2o_block on DPT with my cards
*	Remove duplicate ac97_codec inclusion		(Keith Owens)
X	Tidy up patch for swsuspend			(Pavel Machek)
*	Fix wrong __init in 3c509			(Kasper Dupont)
o	Fix mm/bootmem.c build on cris			(Johan Adolfsson)
*	Remove config tools for 8253x from kernel tree	(Keith Owens)
*	Rename files in aacraid ready for merge		(me)
	of updates
*	Merge bridge specific changes in aac code	(Deanna Bonds)
*	Merge most of the fixups/cleanups for aacraid	(Deanna Bonds)
*	Set PCI masks for the 64 and 32bit aacraids	(me)
*	Don't program up the ali secondary codec for	(me)
	6 channel if you don't have one fitted
*	Block layer copy*user fixups		(Arnaldo Carvalho de Melo)
*	Fix missing intermezzo include		(Marc-Christian Petersen)
o	Slab cache for iobufs		(Andrea Arcangeli, Chuck Lever,
						Christoph Hellwig)
*	Fix intermezzo copy*user		(Arnaldo Carvalho de Melo)
o	down_trylock					(Christoph Hellwig)
*	Fix video compile for split module		(Michal Jaegermann)
	and compiled in
*	Kill 3c59x debug bits				(Andrew Morton)
*	Char fixes for copy*user		(Arnaldo Carvalho de Melo)
*	Fix a few errors in the janitor copy* fixes	(me)

Linux 2.4.19pre8-ac4
o	Fix warnings in pc_keyb.c			(Christoph Hellwig)
*	Fix undefined C in rivafb			(Christoph Hellwig)
*	Fix dnotify warnings				(Christoph Hellwig)
o	Remove unused nfs label				(Christoph Hellwig)
o	Fix vm_validate_enough prototypes		(Christoph Hellwig)
*	Fix wrong comment in agpgart			(Nicolas Aspert)
*	JFFS2 fixes					(David Woodhouse)
o	Hopefully fix zisofs breakage			(David Woodhouse)
*	Remove a defunct soc_probe call			(Christoph Hellwig)
o	Update initrd documentation			(Mark Post)
-	Fix SMP build					(Robert Love)
o	Numa-Q apic timer update			(Martin Bligh)

Linux 2.4.19pre8-ac3
o	Kbuild fixes					(Keith Owens)
*	Fix eepro100 bug/typo				(Michael Rozhavsky)
*	Intel 845G GART support				(Graeme Fisher)
*	Fix tasklet disable/kill in pppoatm		(Luca Barbier)
*	Add another PCI ident to the acenic driver	(Eric Smith)
o	Major IDE updates				(Andre Hedrick)

Linux 2.4.19pre8-ac2
*	Fix more compile problems			(me)
*	Fix a possible hang on shutdown in 3270 tty	(Martin Schwidefsky)
*	Make "make rpm" sane for non x86		(Cesar Cardoso)
*	Two new AC97 codec entries			(Lei Hu)
*	Thread exit race fix				(Dave McCracken)
*	Further sg buffer clearing fix			(Douglas Gilbert)
*	Fix do_mounts printk				(Al Viro)
*	Umembp fixups					(Neil Brown)
*	Umembp shift bug fixup				(me)
o	Kbuild fixes and improvements			(Keith Owens)
*	Add a new tulip clone pci ident entry		(Ohta Kyuma)
*	Fix url on via pci fixups			(Erich Schubert)
*	koi8-ru handling fixes				(Petr Vandrovec)
o	Clean up remaining code to use yield		(Robert Love)
o	Clean up migration_init as per 2.5		(Erich Focht)
o	Clean up maximum real time priorities		(Robert Love)
*	Kill unused variable in bpck6			(Adrian Bunk)
*	Fix dnotify/process exit handling		(Stephen Rothwell)
*	Add another vaio bios to the table		(Yves Lafon)
*	Allow users to disable hyperthreading		(Hugh Dickins)

Linux 2.4.19pre8-ac1
o	Merge with Linux 2.4.19pre8
	-	Fix some compile problems

Linux 2.4.19pre7-ac4
*	Test AMD768 IRQ router support			(me)
*	Fix ext2 build error
*	Improve i810 audio documentation		(Johannes Feigl)
*	Ensure UTS data is in C locale			(Martin Dalecki)
*	Add the Intel ICH4 to the i810 audio driver	(Wang Jun)
*	Fix qlogicfc crash under load			(Dave Miller)
*	Fix snprintf return values in some cases	(Ben LaHaise)
*	Fix a bug that got into the iph5526 code when	(Vineet Abraham)
	networking
*	Add more scanners that respond to all LUNs	(Frank Zago)
*	Synclink PCMCIA wan driver			(Paul Fulghum)
*	Fix sparc64/ppc64 bluetooth ioctl build		(Martin Eriksson)
*	Change 5/6bit codec resolution detect for	(Wan Tat Chee)
	AC97 
*	Fix v4l compile bug in one option case		(Iain Stevenson)
o	Clean up powernow initcalls			("CaT")
o	Add PIO mode support for the Pacific Digital	(Mark Lord)
	ADMA-100i card

Linux 2.4.19pre7-ac3
*       Back merge some documentation fixes      	(Daniel Dickman)
*       Update sisfb driver                     	(Thomas Winischhofer)
o       Remove sync wakeups now O(1) handles it 	(Robert Love)
o       Abstract away need_resched              	(Robert Love)
o       Fix scheduler deadlock during switch_mm 	(Dave Miller)
        on sparc etc
o       Optimise sched_yield                    	(Robert Love)
o       Handle tasks becoming runnable during   	(Robert Love)
        schedule
o       Clean up assumptions about MAX_RT_PRIO  	(Robert Love)
o       Backport of migration fixes/irq off     	(Robert Love
        fixes and migration_init                	 William Irwin)
o       Cleanups from 2.5->2.4 O(1) backport    	(Robert Love)
        | The entire O(1) block above is a backport
        | of all the fixes from Ingo, Robert and others
X       Swsuspend fix crash on boot add cleanups       	(Pavel Machek)
*       Scsi generic buffer tidy up             	(Douglas Gilbert)
*       Correct kd.h definitions                	(Andrej Lajovic)
X       Fix missing include for swsuspend       	(Mauricio Zambrano)
*       Configure.help typo fixes               (Arnaldo Carvalho de Melo)
o       Identify PIV Xeon in mptable            	(James Bourne)
o       Fix "skip_ioapc_setup" compile problem  	(Mikael Pettersson)
o       Additional ext2/ext3 sanity checker     	(Andreas Dilger)
*       Handle very old misconfigured
        NCR53c810 on DECpc XL etc               	(Graham Cobb)
o       Core of support for jfs external log    	(Christoph Hellwig,
                                                	 Dave Kleikamp)
o       Clean up jfs_mknod a little             	(Christoph Hellwig)
o       Sync up 2.4/2.5 jfs changes             	(Christoph Hellwig)
*       PPC compile fixes                       	(Paul Mackerras)
*       Next stage of vm86 fixing               	(Kasper Dupont)
o       Clean up drivers to use vmalloc_to_page 	(Hugh Dickins)
*       Fix missing release in opl3sa2          	(Zwane Mwaikambo)
*       Fix flag type error in rtl8150          	(Rusty Russell)
*       Fix various missing CONFIG_PCI checks   	(me)

Linux 2.4.19pre7-ac2
*	Limit default i2o_block to 64K writes		(me)
	| Several controllers can't handle larger single requests
*	Add power management control to i2o_block	(me)
X	Use chained sg list for i2o_block		(me)
	| Need to load first 8 entries into message for performance still
*	Updated i2o documentation			(me)
*	Fix make xconfig
*	Fix bios reboot sequence			(Robert Hentosh)
*	Kees Cook changed email address			(Kees Cook)
*	Fix a minor SuSv3 violation in SIGURG		(Christopher Yeoh)
o	Make htmldocs fixups				(Erik van Konijnenburg)
o	Make all the slab caches use the "_" convention	(Ryan Mack)
o	Fix flow control problems with TCP over NFS	(Neil Brown)
o	Removepage hooks as per old -ac			(Christoph Rohland)
	| This lets shmfs/ramfs keep accounting straight
	| ramfs needs someone to drop in the other old -ac bits stil
o	Fix via-rhine PCI idents			(Shing Chuang)
*	Backport of 2.5 aha152x update by		(Juergen Fischer)
o	Loop fixups					(Arjan van de Ven)
o	Add HP tachyon idents to cpqfc driver		(Jes Sorensen)
*	Clean up mpu401 failure handling paths		(Zwane Mwaikambo)
*	Ad1848 pnp scanning fixes			(Zwane Mwaikambo)
o	Kill dead URL in maintainers			(Joe Perches)
-	Back out problem bridge update			(Mike Fedyk)
*	Fix sound on Compaq Presario 700		(Santiago Nullo)
o	Fix restore_flags handling in cmd640 probe	(Justin Gibbs)
o	Fix oops from mptable impaired bioses		(Arjan van de Ven)
o	Fix 8139cp/8139too big endian multicast setup	(Naoki Hamada)
*	Fix missing newline in i810 audio printk	(???)
*	Put syscall table back for now			(Steven Hirsch)
*	Fix ips build for some combinations		(Steven Hirsch)
o	NLS makefile tidy				(Urban Widmark)
o	Fix radeonfb build				(Peter Horton)
*	Update poll_out fixes on tty devices		(Sapan Bhatia)
o	32bit uids in acct data				(Chris Wing)

Linux 2.4.19pre7-ac1
o	Merge CPU speed control framework and support (Dave Jones, Russell King
	for VIA processors and AMD K6		Arjan van de Ven, Janne Pänkälä)
o	Merge with 2.4.19pre7
	-	drop out keyb changes (breaks some setups)
*	Lots more i2o debugging work 			(me)
	| I2O now seems to be working again and works
	| for the first time on the AMI Megaraid

Linux 2.4.19pre5-ac3
X	Software suspend initial patch 		(Pavel Machek, Gabor Kuti,..)
	| Don't enable this idly. Its here to get exposure and so
	| people can bring the rest of the code up to meet its needs as
	| well as fix it.
	| Read the docs first!
*	Small fix for the radeonfb			(Peter Horton)
*	Fix highmem truncation on DMA mapping bug	(Dave Miller)
X	Modules are not supposed to hack the syscall	(Arjan van de Ven)
	table so remove the export
*	Add ite sound configuration help		(Steven Cole)

Linux 2.4.19pre5-ac2
*	Fix compile error when using initrd		(Jeff Nguyen)
*	Make the KL133 onboard video happy again	(Andre Pang)
	| and a lot of people working to figure out the right bits
*	Reparent jdb to init and drop lock on exit	(Ishan Jayawardena)
*	Fix radeon corner case				(Arjan van de Ven)
o	Cache more group descriptors on ext2/ext3	(Arjan van de Ven)
*	SAB8253 series wan drivers			(Joachim Martillo)
*	Add more idents for PIIX IDE controllers	(Arjan van de Ven)
*	Lock signals in procfs				(Andrea Arcangeli)
*	Backport of 2.5 BUG_ON() functionality		(Robert Love)
-	Drop -O1 on sched.c - turns out its a CPU
	microcode bug on early Xeon not Linux
*	Fix Radeon fb reset problems as X11 did		(Peter Horton)
*	Radeon acceleration/mtrr updates		(Peter Horton)
o	JFS flushpage updates				(Christoph Hellwig)
*	BeOS file system support			(Will Dyson)
	| original work by Makoto Kato
*	Fix w83877 watchdog SMP compile failure		(Paul Komkoff, me)
*	Fix pty/tty POLL_OUT reporting			(Sapan Bhatia)
*	Update berkshire watchdog driver	(Lindsay Harris, Rob Radez)
o	Clean up duplicated path_init and __user_walk	(Hanna Linder)
	code
*	Enable MMX extensions on Geode GXm		(Zwane Mwaikambo)
o	O(1) scsi free command block finder		(Mark Hemment)
*	Updated IBM serveraid driver			(Jack Hammer)
*	S/390 makefile cross compile fixups		(Pete Zaitcev)

Linux 2.4.19pre5-ac1
o	Merge with 2.4.19pre5

Linux 2.4.19pre4-ac4
o	Fix an additional vm86 case			(Stas Sergeev)
	| Check DOSemu again and this code wants some good review
o	Do sanity checking to avoid mispoking PCI on	(me)
	the CMD640 [noted by Justin Gibbs]
o	Fix promise IDE error recovery			(Manfred Spraul)
o	Ali IDE hang fixes				(Sen Dong)
	| Extracts from a bigger ALi update
*	Ext3 balloc locking fix 			(Andrew Morton)
*	Fix escaped MWAVE configuration			(Thomas Hood)
*	Fix nls_utf8 problems				(Liyang Hu)
*	Fix mmx_memcpy over-prefetching on Athlon	(me)
o	Fix an error return the vm accounting code broke(Andrew Morton)
*	Fix bpck6 build on the powerpc platform		(Jens Schmalzing)
*	Fix bpck6 64bit cleanness and other minor bits	(me)
*	Fix sound Configure.help thinko			(Per von Zweigbergk)
*	Backport the 2.5 wireless driver stuff		(Jean Tourrilhes)
	| So 2.5 driver fix back merging is sane

Linux 2.4.19pre4-ac3
o	Fix NFS pathconf problem			(Neil Brown)
o	IBM memory key ident for usb_storage		(Alexander Inyukhin)
*	Add byte counters to mkiss driver		(Ken Koster)
*	Add more entries to the scsi scan lists		(Arjan van de Ven)
*	More eepro100 variants				(Arjan van de Ven)
*	Update wolfson codec initialisers		(Randolph Bentson)
+	USB serial oops fixes				(Greg Kroah Hartmann)
*	Mad16 register gameport with input layer	(Michael Haardt)
*	Update specialix driver to handle SI v1.x board	(Ismo Salonen)
*	Fix a wdt285 EFAULT return, remove crud		(Ron Gage, me)
*	Fix ioctl return errors on several sound cards	(Ron Gage)

Linux 2.4.19pre4-ac2
*	Hopefully correctly fix the vm86 problems	(Stas Sergeev)
	| Please test wine 16bit/dosemu/XFree stuff
*	Fix panic when writing 0 length ucode chunk	(Tigran Aivazian)
*	Fix incorrect use of hwif->index in ALI IDE	(Martin Dalecki)
*	Fix mmap rbtree corruption bug			(Ben LaHaise)
o	Fix incorrect 10 to 6 byte scsi command switch	(Jens Axboe)
*	TCP correctness fix				(Dave Miller)
*	Correct mwi acronym in docs			(Geert Uytterhoeven)
*	Merge the rest of Promise 20271 support		(YAMAWAKI Teruo)
*	Fix open/close races in indydog			(Dave Hansen)
*	Fix compile problem with ibm hotplug		(Greg Kroah-Hartmann)
*	Save the .config file in make rpm		(Kelly French)
*	Add another vaio with swapped minutes		(Michael Piotrowski)
o	Further atm fixes				(Maksim Krasnyanskiy 
							 Marcell Gal)
o	Even more atm fixes				(Francois Romieu)
*	USB support for palm m130			(Udo Eisenbarth)
*	USB fix for pegasus hotplug crash		(Petko Manolov)
* 	USB request sense help for some scanners	(Oliver ?)
*	USB support for Optus@home 			(Oliver ?)
*	USB printer updates			(David Paschal, Pete Zaitcev)
*	Work around USB ATEN keyboard switches		(Vojtech Pavlik)
*	PWC usb camera updates				("Nemosoft")
*	Small updates to the USB hub code		(Itai Nahshon)
*	Fix spinlock handling bugs in ipaq USB		(Ganesh Varadarajan)
*	OHCI fixes					(David Brownell)
*	USB docs update					(David Brownell)
*	UHCI fixes					(Johannes Erdfelt)
*	Quieten a USB message to debug			(Greg Kroah-Hartmann)
*	USB bandwidth reporting				(David Brownell)
*	Fix msync SuS v3 compliance			(Chris Yeoh)
*	CS8900 fixes (need testing)			(Paul Komkoff)
*	Adapt HP100 driver to pci api			(Jeff Garzik)
*	Acenic updates - fix leak and Tigon1		(Jes Sorensen)
*	DE620 region handling fixes			(K Kasprzak)
*	DLink DL2K gige updates			(Edward Peng, Jeff Garzik)
*	pcnet32 leak fix				(Jeff Garzik)
*	pcnet32 types fixes for non x86			(Anton Blanchard)
*	pcnet32 assorted fixes				(Dave Engebretsen)
*	pcnet32 fixes					(Paul Mackerras)
*	Fix missing linux/delay.h from eepro100		(me)
*	Further pcnet32 cleanup and probe fixes		(Go Taniguchi)
*	Merge gcc3 warning fixes for copy/csum		(Jeff Garzik)
*	Fix bmac build					(Joshua Uziel)
*	DE4x5 slight tidy up				(Jeff Garzik)
*	More AC97 ident strings				(Peter Christy)

Linux 2.4.19pre4-ac1
o	Merge 2.4.19pre4
*	Add PCI idents for mobility parallel port	(me)
o	Fix crash on boot with LLC if no devices present(me)

Linux 2.4.19pre3-ac6
o	Fix the oops initialising the CD-ROM		(Andre Hedrick)
*	Add devexit_p() to the wdt_pci watchdog		(Adrian Bunk)
o	Fix lm_sensors compile				(Eyal Lebedinsky)
o	Remove some dead JFS oddments			(Christoph Hellwig)
*	SCSI generic update			(Doug Gilbert, Travers Carter)
o	VM86 exception fixups			(Kasper Dupont, Manfred Spraul)
*	Fix an fcntl error corner case to match SuS	(Christopher Yeoh)

Linux 2.4.19pre3-ac5
*	Further IDE updates				(Andre Hedrick)
*	Reduce ide tape debug noise			(Alfredo Sanjuán)
*	Sync devices on final close not each close	(Miquel van Smoorenburg)
*	Make max busses/irqs dynamic on x86		(James Cleverdon)
	| Needed for big IBM boxen
*	Remove exp_find in NFS (never used)		(Al Viro)
*	Fix read locking on NFS export_table		(Erik Habbinga)
*	Fix possible NFS error path mnt/dentry leak	(Al Viro)
*	Use MKDEV macro in NFS device create		(GOTO Masanori)
*	Clean up stale fh stats				(Neil Brown)
o	Tidy nfsd_lookup				(Al Viro)
o	nfsd_setattr fixes				(Neil Brown)
o	Tidy up nfsd vfs calls				(Neil Brown)
o	Clean up nfsd syscall interface			(Neil Brown)
o	Fix fat NFS handle interfaces			(Neil Brown)
o	Tidy up export list handling for NFS		(Al Viro)
o	Use seq_file for NFS exports proc file		(Al Viro)
o	Support for deviceless file system exports	(Steven Whitehouse)
o	Remove big kernel lock use for most of nfsd	(Neil Brown)
o	Convert sunrpc code to use generic linux lists	(Neil Brown)
o	Tidy up svc_sock NFS locking on SMP		(Neil Brown)
o	Improve tcp error/close handling		(Neil Brown)
o	Close down idle NFS tcp sockets			(Neil Brown)
o	NFS TCP fixes for buffer space tracking		(Neil Brown)
o	Handle TCP RPC service flooding			(Neil Brown)
o	Enable NFS over TCP via config options		(Neil Brown)

Linux 2.4.19pre3-ac4
o	Ensure jfs readdir doesn't spin on bad metadata	(Dave Kleikamp)
o	Fix iconfig with no modules			(Randy Dunlap)
*	Don't enfore rlimit on block device files	(Peter Hartley)
*	Add belkin wireless card idents			(Brendan McAdams)
*	Add HP VA7400 to the scsi blacklist quirks	(Alar Aun)
o	JFS race fix					(Dave Kleikamp)
*	Fix wafer5823 watchdog merge error I made	(Justin Cormack)
*	Fix Config rule for phonejack pcmcia card	(Eyal Lebedinsky)
o	Test improved OOM handler for rmap		(Rik van Riel)
*	Update defconfig/experimental bits		(Neils Jensen)
*	The incredible shrinking kernel patch		(Andrew Morton)
*	Clean up BUG() implementation			(Andrew Morton)

Linux 2.4.19pre3-ac3
*	Doh fixed the SYSVIPC build problem		(Everyone...)
o	Added 802.2LLC support			(Arnaldo Carvalho de Melo)
	| Based on 2.0 code contributed by Procom
*	Fix i2o build as module				(Mark Cooke)
*	Blacklist for machines where local apic fails	(Mikael Pettersson)
*	Clean up wdt_pci				(Zwane Mwaikambo)

Linux 2.4.19pre3-ac2
o	Hopefully fixed all the as accounting bugs	(me)
o	Bit more LS220 work (nothing useful yet)	(me)
o	Change should be long not int in shmem acct	(me)
o	Ignore MAP_NORESERVE in mode 2/3 accounting	(me)
*	Fix pci bar flag parsing			(Russell King)
*	Handle ELF setup_arg_pages failure		(Russell King)
*	AT1700 filter fix				(Sawa)
o	S/390 fix for O(1) scheduler			(Pete Zaitcev)
o	Fix /proc/kcore for non zero memory start	(Russell King)
*	Update USB config files				(Greg Kroah-Hartmann)
*	TCP minisocks fixes				(Dave Miller)
*	dnotify fixes					(Stephen Rothwell)
*	Remove pointles sysrq-L				(Russell King)
*	Reparent khubd to init				(Andrew Morton)
*	EEpro100 test updates				(Arjan van de Ven)
*	Use named initializers in hwc_con		(Pete Zaitcev)
*	SHM ipc fix					(Paul Larson)
*	Further printk level fixes			(Denis Vlasenko)
*	Revert epic100 changes - reports of problems	(me)
*	Wafer WDT watchdog driver			(Justin Cormack)
	| I did some cleanup - Justin please double check it
*	ITE8330G PIRQ map support			(Tobias Diedrich)
*	Trivial khttpd logging bug fix			(Rogier Wolff)
*	Stop module autoloader making user /proc/pid	(Andreas Ferber)
	dir root owned
*	Handle TF flag properly on debug trap		(Christoph Hellwig,
					Arjan van de Ven, Stephan Springl)
*	ALi M1701 watchdog driver			(Stve Hill)
	| I tidied/fixed this one too so please check
o	Add iconfig  (save/extract config from kernel	(Randy Dunlap)
	image file)
*	Add mk712 touchscreen driver			(Daniel Quinlan)
	| Fixed various bugs in it - Dan please check

Linux 2.4.19pre3-ac1
o	Merge with 2.4.19pre3
	-	Revert buggy bluesmoke change
	-	Add missing pppox header change
*	Next SIS ide update				(Lionel Bouton)
*	Only try the flush and recycle trick for 	(me)
	known buggy I2O controllers.
*	Clean up module junk and use new init style	(me)
	for I2O.
*	Don't use cache hints on dim i2o controllers	(me)
*	Add vmalloc_to_page to 2.4 from 2.5		(Gerd Knorr)
o	JFS updates			(Christoph Hellwig, Dave Kleikamp)
*	Fix boot_cpu_data corruption bug		(Mikael Pettersson)
*	Clean up ppp vfree paths			(David Woodhouse)
*	Emagic EMI usb driver				(Tapio Laxström)
*	Edgeport fixes for multiple device case	 	(Greg Kroah-Hartmann)	
*	Ethtool support for catc usb			(Brad Hards)
*	Update to pegasus driver in base tree		(Petko Manolov)
*	Update USB maintainers				(Greg Kroah-Hartmann)
*	IPAQ usb driver fixup				(Ganesh Varadarajan)
*	Allow usbfs name for 2.5 compatibility		(Greg Kroah-Hartmann)
o	Committed_AS without a space in procfs		(Andy Dustman)
*	Fix an NFS file creation problem		(Trond Myklebust)
*	Fix a missing ksym				(Greg Kroah-Hartmann)
*	Increase init delay on ALI5451 audio setup	(Harald Jenny)
	| Needed for Acer Travelmate 521TE
*	Fix printk message levels in pci code		(Denis Vlasenko)
*	Add another laptop to the buggy APM tables	(Mihnea-Costin Grigore)
*	Fix an obscure acct race			(Bob Miller)
*	Sonypi driver update				(Stelian Pop)
*	Fix devfs glitch with namespace stuff		(Paul Komkoff, Al Viro)

Linux 2.4.19pre2-ac4
*	Initial Ricoh ZVbus support			(Marcus Metzler)
o	PnPBIOS fixes					(Brian Gerst)
*	Fix a case where sync_one might not start an	(Ben LaHaise)
	inode writeout
*	Corrected atm locking fix			(Maksim Krasnyanskiy)
*	mp table parsing corner case fix		(James Cleverdon)
o	NFS over JFS directory offset fix		(Christoph Hellwig)
*	Update reisefsprogs version			(Paul Komkoff)
*	RME Hammerfall driver update			(Günter Geiger)
*	Fix an off by one in the bluesmoke reporting	(Dave Jones)
*	Make irnet disconnect hang up ppp		(Jean Tourrilhes)
*	Fix abuse of cli() in irda socket connect	(Jean Tourrilhes)
*	Add help text to patch-kernel script		(Damjan Lango)
*	USB irda updates				(Jean Tourrilhes)
*	IRDA link layer updates				(Jean Tourrilhes)
*	Add WD xd signature to 2.4 (from 2.2)		(Jim Freeman)
*	Update sc1200 watchdog				(Zwane Mwaikambo)
*	Switch wdt501 watchdog driver to bitops		(me)
*	Much updated LSI logic MPT fusion drivers	(Pam Delaney)
*	Wavelan driver updates				(Jean Tourrilhes)
*	Fix a race where we could hit init_idle after	(Kip Walker)
	freeing it (from rest_init)
*	Raylink driver bugfixes				(Jean Tourrilhes)
o	Switch 2.4 to using a shared zlib		(David Woodhouse)
*	Fix w83877 SMP deadlock, clean up locking	(me)
*	IBM lanstreamer update				(Kent Yoder)
*	Fix 32bitism in the PM code			(Pavel Machek)
*	Make irqsave use unsigned long for consistency	(Pavel Machek)
	| Just fixes a few exceptions
*	Make i2o_block fallback to blkpg for ioctls	(me)
*	All pids in use handling			(Paul Larson)
*	IDE code wasn't using ide_free_irq		(William Jhun)
*	Fix non procfs build				(Eric Sandeen)
*	Cyberjack bug fix				(Greg Kroah-Hartmann)
*	USB vicam fixes					(Oliver Neukum)
*	Add another device to the ftdi driver		(Greg Kroah-Hartmann)
*	UHCI performance fixes				(Johannes Erdfelt)
*	STV680 bug fixes				(Kevin Sisson)
*	Kaweth bug fixes				(Oliver Neukum)
*	Update hpusbscsi driver				(Oliver Neukum)
*	Update OV511 driver				(Mark McClelland)
*	Update usb-ipaq driver to support journada	(Ganesh Varadarajan)
*	Fix a bug in the USB skeleton driver		(Holger Waechtler)
*	Further SiS IDE updates				(Lionel Bouton)
*	Fix ufs mount failure bug			(Andries Brouwer)
*	Allow the max user frequency for the rtc to	(Mike Shaver)
	be configurable
*	HPT37x crash on init fixups			(Vojtech Pavlik)

Linux 2.4.19pre2-ac3
o	Fix quota deadlock and extreme load corruption	(Jan Kara, Chris Mason)
*	MIPS config fix					(Ralf Baechle)
*	Update AGP config entry				(Daniele Venzano)
*	SMBfs NLS oops fix				(Urban Widmark)
*	Fix expand_stack locking hang on OOM		(Kevin Buhr)
*	Restore 10Mbit half duplex eepro100 fix		(me)
*	3c509 full duplex and documentation		(David Ruggiero)
*	3c509 power management				(Zwane Mwaikambo)
*	Remove more surplus llseek methods		(Robert Love)
X	ATM locking fix					(Frode Isaksen)
*	Merge extra sound help texts			(Steven Cole)
	| plus one typo fix
*	Add help for IXJ pcmcia configuration		(Steven Cole, me)
	| Rewrote the text somewhat

Linux 2.4.19pre2-ac2
-	Fix a mismerge (may explain the patch weirdo)
*	Fix highmem + sblive				(Daniel Bertrand)
*	Reiserfs updates				(Oleg Drokin)
*	Auto enable HT on HT capable systems		(Arjan van de Ven)
-	Fix init/do_mounts O(1) scheduler merge glitch	(Greg Louis)
o	Fix drm build problem on CPU=386		(Mark Cooke)
*	Fix incorrect sleep in ZR36067 driver		(me)
*	Add missing cpu_relax to iph5526 driver		(me)

Linux 2.4.19pre2-ac1
*	Merge aic7xxx update				(Justin Gibbs)
*	Fix handling of scsi 'medium error: recovered'	(Justin Gibbs)
*	Further request region fixups			(Marcus Alanen)
*	Add interlace/doublescan to voodoo1/2 fb driver	(Urs Ganse)
	| interlace is always handy with 3d glasses..
o	Merge O(1) scheduler				(Ingo Molnar)
	| Thanks to Martin Knoblauch for doing the merge work
	| Non x86 ports may need to clean up their mm/fault.c
*	Lseek usage cleanup				(Robert Love)
o	Merge with 2.4.19pre2
	-	Fixed bogus sysctl definitions
	-	Fixed incorrect MODULE_LICENSE backout
	-	Fixed gratuitous supercede spelling change
	-	Fixed double patches from mips people
	-	Fixed incorrect link order from mips people
	-	Fixed broken config rules from mips people
	-	Made cciss build
	-	Remove half written "meth.c" driver
*	Fix up some of the watchdog api text		(me)
	| Janitor job - go through that and make all the drivers
	| support all the things ('V' NOWAYOUT and ioctl core)
*	Fix wrong order in MAINTAINERS			(me)
*	Remove roadrunner reference from MAINTAINERS	(me)

Linux 2.4.19pre1-ac2
*	Fix chown/chmod on shmemfs			(me)
*	Fix accounting error in the shm code		(me)
o	Turn on mode2/mode3 overcommit protection	(me)
*	w83877f watchdog fix compile for SMP		(Mark Cooke)
*	Fix ide=nodma for serverworks			(Ken Brownfield)
*	USB2 controller support				(Greg Kroah-Hartmann)
*	Add more devices to the visor driver (m515,clie)(Greg Kroah-Hartmann)
*	IBM USB camera driver updates			(Greg Kroah-Hartmann)
*	USB auerswald driver				(Wolfgang Muees)
*	Trivial random match up with 2.2		(Marco Colombo)
*	Spelling fixes					(Jim Freeman)
*	Next batch of time_*() fixups			(Tim Schmielau)
*	Update video4linux API docs			(Gerd Knorr)
*	Merge some comment fixups			(John Kim)
*	ymfpci sync					(Pete Zaitcev)
*	Update maintainers to add pm3fb			(Romain DOLBEAU)
*	Hotplug updates (docs, fs, compaq driver)	(Greg Kroah-Hartmann)
*	IBM hotplug support	(Irene Zubarev, Tong Yu, Jyoti Shah, Chuck Cole)
*	ACPI hotplug driver support		(Hiroshi Aono, Takayoshi Kochi)
*	Blink keyboard lights on x86 panic		(Andi Kleen)
*	Further Configure.help changes			(Steven Cole)
o	Merge a version of the sard I/O accounting	(Stephen Tweedie,
							 Christoph Hellwig)
*	SC1200 watchdog driver				(Zwane Mwaikambo)
*	Fix address ordering for 36bit MCE on x86	(Dave Jones)

Linux 2.4.19pre1-ac1
o	Merge with 2.4.19-pre1

Linux 2.4.18-ac1
o	Merge with 2.4.18 proper
o	Add missing -rc4 diff
o	Use attribute notifiers to account shmemfs	(me)
o	Initial luxsonor LS220/LS240 driver code	(me)
	| This is just setup code and only in the tree because
	| its where I keep my hacks in progress

Linux 2.4.18rc2-ac2
o	Fix a corruption problem in the jfs dir table	(Dave Kleikamp)
o	Fix trap when extending a single extent of	(Dave Kleikamp)
	over 64Gb in JFS
*	NBD deadlock fix				(Steven Whitehouse)
*	Fix device ref counting in netrom stack		(Tomi Manninen)
*	Fix shmemfs link counting			(Christoph Rohland)
*	Fix potential scsi disk oops			(Peter Wong)
*	eepro100 carrier init fix			(Jeff Garzik)
*	Fix wrong kfree in netrom stack			(Tomi Manninen)
*	Add TI1250 inits to ZV bus support		(me)
	| Zoom video now works on the IBM TP600 at least..
*	Fix off by one on loop devices limit		(Heinz Mauelshagen)
X	Improve handling of psaux open with no mouse	(Christoph Hellwig)
	present
*	3COM 3c359 token ring driver			(Mike Phillips)
*	Fix a case where hpfs didnt set block size	(Chris Mason)
	early enough
*	Remove use of lock_kernel in softdog driver	(me)
*	Make olympic driver use spinlocks not 		(Mike Phillips)
	lock_kernel
+	Fix type of detected devices in md.c		(Jakob Kemi)
*	Changes and defconfig update			(Niels Jensen)
o	PNP BIOS driver updates				(Thomas Hood)
*	Turn off excess printks in pnp quirk reporting	(Andrey Panin)
*	Add documentation for ITE I2C			(Steven Cole)
*	Add documentation for other zoran cards		(Steven Cole)
*	Add an SC520 watchdog, and enable wd8387ff 	(Scott Jennings)
*	Cleaned up and fixed some SC520 watchdog bugs	(me)
	| Scott - can you double check these
*	Fix return on generic lib/string.c memcmp	(Georg Nikodym)
*	Further zoom video cleanups			(me)

Linux 2.4.18rc2-ac1
o	Merge with 2.4.18rc2
*	Ignore i810 modem codecs			(me)
o	Core of address space accounting code		(me)
	| Enforcement, ptrace and some shmem corner bits to do
*	Fix security hole in shmfs			(me)
o	Fix various bits of 64bit file I/O in shmem	(me)
o	Merge with rmap12f				(Rik van Riel and co)

Linux 2.4.18pre9-ac4
*	SIS IDE driver update (handle with care)	(Lionel Bouton)
*	First set of I2O endian cleanups		(me)
*	Make i2o_pci.c 64bit/BE clean			(me)
*	Maybe fix crash on i2o scsi abort/reset paths	(me)
*	Make i2o use the passed scsi direction flag	(me)
*	Fix awk failure path in menuconfig		(Andrew Church)
*	Merge varies doc updates			(Steven Cole)
*	Add serial support for the Lava Octopus-550	(Jim Treadway)
*	OPL3SA2 cleanup					(Zwane Mwaikambo)
o	Add missing blkdev_varyio export		(Todd Roy)
*	Update Changes file, config and experimental	(Niels Jensen)
	checks
*	Fix highmem warning in aacraid			(Andrew Morton)
*	Make tpqic02 use new style request region	(Marcus Alanen)
*	Only turn off mediagx/geode TSC on 5510/5520	(me)
	| From information provided by Hiroshi MIURA
*	Massively clean up the AGP enable and bugfix it	(Bjorn Helgaas)
*	Fix oops if you try to use the RW wq locks	(Bob Miller)
*	Remove FPU usage in neomagic fb			(Denis Kropp)
o	Merge IBM JFS			(Steve Best, Dave Kleikamp, 
					 Barry Arndt, Christoph Hellwig, ..)
*	Updated sis frame buffer driver			(Thomas Winischhofer)

Linux 2.4.18pre9-ac3
*	Clean up various macros and misuse of ;		(Timothy Ball)
*	Correct procfs locking fixup			(Al Viro)
o	Speed up ext2/ext3 synchronous mounts		(Andrew Morton)
*	Update IDE DMA blacklist			(Jonathan Kamens)
o	Update to XFree86 DRM 4.2 (compatible to 4.1)	(Rik Faith, 
	and adds I830 DRM				 Jeff Hartmann,
							 Keith Whitwell,
							 Abraham vd Merwe
							 and others)
*	IBM Lanstreamer updates				(Mike Phillips)
*	Fix acct rlimit problem (I hope)		(me)
	| Problem noted by Ian Allen
o	Automatically set file limits based on mem size	(Andi Kleen)
*	Correct scsi reservation conflict handling	(James Bottomley)
	and add the scsi reset api code
o	Add further kernel docs				(me)
o	Merge to rmap-12e				(Rik van Riel and co)
	|merge patch from Nick Orlov
*	Small fix to the eata driver update		(Dario Ballabio)


Linux 2.4.18pre9-ac2
*	Nat Semi now use their own ident on the Geode	(Hiroshi Miura)
*	Put #error in two files that need FPU fixups	(me)
*	Correct a specific mmap return to match posix	(Christopher Yeoh)
*	Add Eepro100/VE ident				(Hanno Boeck)
*	Add provides for DRM to the kernel make rpm	(Alexander Hoogerhuis)
*	Fix a problem where vm86 irq releasing could be	(Stas Sergeev)
	missed
*	EATA and U14/34F driver updates			(Dario Ballabio)
*	Handle EMC storage arrays that report SCSI-2 	(Kurt Garloff)
	but want REPORT_LUNs
*	Update README, defconfig, remove autogen files	(Niels Jensen)
*	Add AFAVLAB PCI serial support			(Harald Welte)
*	Fix incorrect resource free in eexpress		(Gianluca Anzolin)
o	Variable size rawio optimisations		(Badari Pulavarty)
*	Add AT's compatible 8139 cardbus chip		(Go Taniguchi)
*	Fix crash with newest hpt ide chips		(Arjan van de Ven)
*	Fix tiny SMP race in pid selection		(Erik Hendriks)
o	Hopefully fix pnpbios crash caused by early	(me)
	kernel_thread creation

Linux 2.4.18pre9-ac1
o	Initial merge of DVD card driver  (Christian Wolff,Marcus Metzler)
	| This is just an initial testing piece. DVB needs merging
	| properly and this is only a first bit of testing
*	Random number generator support for AMD768	(me)
*	Add AMD768 to i810 driver pci ident list	(me)
o	Initial AMD768 power management work		(me)
	| Unfinished pending some docs clarifications
*	Fix bugbuf mishandling for modular es1370	(me)
*	Fix up i2o readl abuse, post_wait race, and	(me, Arjan van de Ven)
	some deadlock cases
*	Added cpu_relax to yam driver 			(me)
*	Fixup AMD762 if the BIOS apparently got it wrong(me)
	(eg ASUS boards)
*	MP1.4 alignment fixup
*	pcwd cleanup, backport of fixes from 2.5	(Rob Radez)
*	Add support for more Moxa cards to mxser	(Damian Wrobel)
*	Add remaining missing MODULE_LICENSE tags	(Hubert Mantel)
*	Fix floppy reservation ranges			(Anton Altaparmakov)
*	Fix max file size setup				(Andi Kleen)

Linux 2.4.18pre7-ac3
*	Fix a wrong error return in the megaraid driver	(Arjan van de Ven)
*	FreeVXFS update					(Christoph Hellwig)
*	Qnxfs update					(Anders Larsen)
o	Fix non compile with PCI=n			(Adrian Bunk)
-	Fix DRM 4.0 non compile in i810			(me)
*	Drop out now dead CLONE thread/parent fixup	(Dave McCracken)
*	Make NetROM incoming frame check stricter	(Tomi Manninen)
*	Use sock_orphan in AX.25/NetROM			(Jeroen PE1RXQ)
*	Pegasus update					(Petko Manolov)
o	Make reparent_to_init and exec_usermodehelper	(Andrew Morton)
	use set_user, fix a tiny set_user SMP race
*	Mark framebuffer mappings VM_IO			(Andrew Morton)
*	Neomagic frame buffer driver			(Denis Kropp)
	- Needs FPU code fixing before it can be merged
*	Hyperthreading awareness for MTRR driver
*	Correct NR_IRQ with no apic support		(Brian Gerst)
*	Fix missing includes in sound drivers		(Michal Jaegermann)

Linux 2.4.18pre7-ac2
*	i810 audio driver update			(Doug Ledford)
*	Early ioremap for x86 specific code		(Mikael Pettersson)
	| This is needed to do things like apic/dmi detect early enough
*	Pentium IV APIC/NMI watchdog			(Mikael Pettersson)
*	Add C1MRX support to sonypi driver		(Junichi Morita)
*	Fix "make rpm" with two '-' in extraversion	(Gerald Britton)
*	Fix aacraid hang/irq storm on i960 boards	(Chris Pascoe)
*	Fix isdn audio compiler behaviour dependancy	(Urs Thuermann)
*	YAM driver fixes				(Jean-Paul Roubelat)
*	ROSE protocol stack update/fixes		(Jean-Paul Roubelat)
*	Fix UFS/CDROM oops				(Zwane Mwaikambo)
*	Fix nm256 hang on Dell Latitude			(origin unknown)
	| Please test this tree with other NM256 based boxes and check
	| those still work...
o	Merge PnPBIOS patch		(Thomas Hood, David Hinds, Tom Lees,
					 Christian Schmidt, ..)
*	Merge new sis frame buffer drivers		(Thomas Winischhofer)
*	cs46xx oops fix					(Mike Gorse)
*	Fix a second cs46xx bug related to this		(me)
*	Fix acpitable oopses on boot and other problems	(James Cleverdon)
*	Fix io port type on the hpt366 driver		(Pete Popov)
*	Updated matrox drivers				(Petr Vandrovec)
*	IPchains fixes needed for 2.4.18pre7
*	IDE config text updates for the IDE patches	(Anton Altaparmakov)
*	Merge the first bits of ZV support		(Marcus Metzler)
*	Add initial ZV support to yenta socket driver	(me)
	for TI cards
*	Fix pirq routing on the CS5530 			(me)
	| Finally the palmax pcmcia/cardbus works properly

Linux 2.4.18pre7-ac1
o	Merge with 2.4.18pre7				(Arjan van de Ven)
	| + some quota fixups redone by me
	| several 18pre7 netfilter bugs left unfixed for now
o	Rmap-12a					(Rik van Riel and co)

Linux 2.4.18pre3-ac2

*	Re-merge the IDE patches			(Andre Hedrick and co)
*	Fix check/request region in ali_ircc and lowcomx(Steven Walter)
	com90xx, sealevel, sb1000
*	Remove unused message from 6pack driver		(Adrian Bunk)
*	Fix unused variable warning in i60scsi		(Adrian Bunk)
*	Fix off by one floppy oops			(Keith Owens)
*	Fix i2o_config use of undefined C		(Andreas Dilger)
*	Fix fdomain scsi oopses				(Per Larsson)
*	Fix sf16fmi hang on boot			(me)
+	Add bridge resources to the resource tree	(Ivan Kokshaysky)
*	Fix iphase ATM oops on close in on case	   (Till Immanuel Patzschke)
*	Enable OOSTORE on winchip processors		(Dave Jones, me)
	| Worth about 10-20% performance 
*	Code Page 1250 support				(Petr Titera)
*	Fix sdla and hpfs doc typos			(Sven Vermeulen)
o	Document /proc/stat				(Sven Heinicke)
*	Update cs4281 drivers				(Tom Woller)
	| Fixes xmms stutter, remove wrapper code
	| handle tosh boxes, allow record device change
	| trigger wakeups on ioctl triggered changes
+/o/X	Fix locking of file struct stuff found by ibm	(Dipankar Sarma)
	audit
o	Use spin_lock_init in serial.c			(Dave Miller)
*	Fix AF_UNIX shutdown bug			(Dave Miller)

Linux 2.4.18pre3-ac1

o	32bit uid quota
o	rmap-11b VM					(Rik van Riel,
							 William Irwin etc)
*	Make scsi printer visible			(Stefan Wieseckel)
*	Report Hercules Fortissimo card			(Minya Sorakinu)
*	Fix O_NDELAY close mishandling on the following	(me)
	sound cards: cmpci, cs46xx, es1370, es1371,
	esssolo1, sonicvibes
*	tdfx pixclock handling fix			(Jurriaan)
*	Fix mishandling of file system size limiting	(Andrea Arcangeli)
*	generic_serial cleanups				(Rasmus Andersen)
o	serial.c locking fixes for SMP - move from cli	(Kees)
	too
*	Truncate fixes from old -ac tree		(Andrew Morton)
*	Hopefully fix the i2o oops			(me)
	| Not the right fix but it'll do till I rewrite this
*	Fix non blocking tty blocking bug		(Peter Benie)
o	IRQ routing workaround for problem HP laptops	(Cory Bell)
*	Fix the rcpci driver				(Pete Popov)
*	Fix documentation of aedsp location		(Adrian Bunk)
*	Fix the worst of the APM ate my cpu problems	(Andreas Steinmetz)
*	Correct icmp documentation			(Pierre Lombard)
*	Multiple mxser crash on boot fix	(Stephan von Krawczynski)
o	ldm header fix					(Anton Altaparmakov)
*	Fix unchecked kmalloc in i2c_proc	(Ragnar Hojland Espinosa)
*	Fix unchecked kmalloc in airo_cs	(Ragnar Hojland Espinosa)
*	Fix unchecked kmalloc in btaudio	(Ragnar Hojland Espinosa)
*	Fix unchecked kmalloc in qnx4/inode.c	(Ragnar Hojland Espinosa)
*	Disable DRM4.1 GMX2000 driver (4.0 required)	(me)
*	Fix sb16 lower speed limit bug			(Jori Liesenborgs)
*	Fix compilation of orinoco driver		(Ben Herrenschmidt)
*	ISAPnP init fix					(Chris Rankin)
o	Export release_console_sem			(Andrew Morton)
*	Output nat crash fix				(Rusty Russell)
*	Fix PLIP					(Niels Jensen)
*	Natsemi driver hang fix				(Manfred Spraul)
*	Add mono/stereo reporting to gemtek pci radio	(Jonathan Hudson)

Re: Linux 2.4.20-pre1

[Jean Tourrilhes]

	Hi,

	Sorry to disturb, but it seems that kernel.org didn't pick up
2.4.20-pre1 (or I'm looking at the wrong places).

	I'm asking because I've just finished testing my IrDA update
for 2.4.20, and you've just included some useless IrDA change that
probably render my patch worthless. So, I need to check and see how
much more work I need to do (or if I should just give up).

	Regards,

	Jean

Re: Linux 2.4.20-pre1

[Marcelo Tosatti]

On Mon, 5 Aug 2002, Jean Tourrilhes wrote:

> 	Hi,
>
> 	Sorry to disturb, but it seems that kernel.org didn't pick up
> 2.4.20-pre1 (or I'm looking at the wrong places).
>
> 	I'm asking because I've just finished testing my IrDA update
> for 2.4.20, and you've just included some useless IrDA change that
> probably render my patch worthless

What you mean I included some useless IrDA patch?

> So, I need to check and see how much more work I need to do (or if I
> should just give up).

Re: Linux 2.4.20-pre1

[Jean Tourrilhes]

On Tue, Aug 06, 2002 at 09:33:45AM -0300, Marcelo Tosatti wrote:
> 
> 
> On Mon, 5 Aug 2002, Jean Tourrilhes wrote:
> 
> > 	Hi,
> >
> > 	Sorry to disturb, but it seems that kernel.org didn't pick up
> > 2.4.20-pre1 (or I'm looking at the wrong places).
> >
> > 	I'm asking because I've just finished testing my IrDA update
> > for 2.4.20, and you've just included some useless IrDA change that
> > probably render my patch worthless
> 
> What you mean I included some useless IrDA patch?

	Yep, tons of these :
-----------------------------------------------
-        IRDA_DEBUG(4, __FUNCTION__ "(), speed=%d (was %d)\n", speed, 
-		   self->speed);
+        IRDA_DEBUG(4, "%s(), speed=%d (was %d)\n", __FUNCTION__,
+        	speed, self->speed);
-----------------------------------------------
	Between this and fixing a Oops or Deadlock, I'll take the
second any day.
	I don't care on those patch in general, I'm not a control
freak, except that being so pervasive they are guaranteed to screw up
my own patches. That's why yesterday I *explicitely* asked you and
Alan if anything was pending, so that I could avoid wasting my time
and instead wait for the next release doing something else.
	I guess it's too late, I already wasted my afternoon.

	The second thing that bugs me is that because those patches
pass behind my back, they won't get applied to *both* 2.4.X and
2.5.X. Because of that, keeping 2.4.X and 2.5.X in synch is an
exercise in futility.
	But maybe you are finding that there is already too many IrDA
maintainers.

	I'll send you the Wireless patches, and I'll try to respin the
IrDA patches this afternoon (i.e. please screw me again !).

	Regards,

	Jean

Re: Linux 2.4.20-pre1

[Marcelo Tosatti]

On Tue, 6 Aug 2002, Jean Tourrilhes wrote:

> On Tue, Aug 06, 2002 at 09:33:45AM -0300, Marcelo Tosatti wrote:
> >
> >
> > On Mon, 5 Aug 2002, Jean Tourrilhes wrote:
> >
> > > 	Hi,
> > >
> > > 	Sorry to disturb, but it seems that kernel.org didn't pick up
> > > 2.4.20-pre1 (or I'm looking at the wrong places).
> > >
> > > 	I'm asking because I've just finished testing my IrDA update
> > > for 2.4.20, and you've just included some useless IrDA change that
> > > probably render my patch worthless
> >
> > What you mean I included some useless IrDA patch?
>
> 	Yep, tons of these :
> -----------------------------------------------
> -        IRDA_DEBUG(4, __FUNCTION__ "(), speed=%d (was %d)\n", speed,
> -		   self->speed);
> +        IRDA_DEBUG(4, "%s(), speed=%d (was %d)\n", __FUNCTION__,
> +        	speed, self->speed);
> -----------------------------------------------
> 	Between this and fixing a Oops or Deadlock, I'll take the
> second any day.
> 	I don't care on those patch in general, I'm not a control
> freak, except that being so pervasive they are guaranteed to screw up
> my own patches. That's why yesterday I *explicitely* asked you and
> Alan if anything was pending, so that I could avoid wasting my time
> and instead wait for the next release doing something else.
> 	I guess it's too late, I already wasted my afternoon.
>
> 	The second thing that bugs me is that because those patches
> pass behind my back, they won't get applied to *both* 2.4.X and
> 2.5.X. Because of that, keeping 2.4.X and 2.5.X in synch is an
> exercise in futility.
> 	But maybe you are finding that there is already too many IrDA
> maintainers.
>
> 	I'll send you the Wireless patches, and I'll try to respin the
> IrDA patches this afternoon (i.e. please screw me again !).

I can back out those patches if you want. Will that help you?

Re: Linux 2.4.20-pre1

[Jean Tourrilhes]

On Tue, Aug 06, 2002 at 01:31:56PM -0300, Marcelo Tosatti wrote:
> 
> > 	I'll send you the Wireless patches, and I'll try to respin the
> > IrDA patches this afternoon (i.e. please screw me again !).
> 
> I can back out those patches if you want. Will that help you?

	No point in going backward, what's done is done, I'm already
working on 2.4.20-pre1. And I'm starting to cool down.

	Jean

Re: Linux 2.4.20-pre1

[David S. Miller]

   From: Jean Tourrilhes <jt@bougret.hpl.hp.com>
   Date: Tue, 6 Aug 2002 10:17:36 -0700
   
   	The second thing that bugs me is that because those patches
   pass behind my back, they won't get applied to *both* 2.4.X and
   2.5.X. Because of that, keeping 2.4.X and 2.5.X in synch is an
   exercise in futility.

This is an old topic.  If cleanups get submitted they are going
to go in.  If this means that someone has to redo a patch, that
is just a part of life.

Nobody is "above the law", sort of speak, when it comes to these
things.  Cleanups and compile warning fixes are not required to
go through the maintainer of a piece of code.

About IRDA wrt. 2.4.x vs 2.5.x, it requires a partial rewrite in 2.5.x
anyways so don't get worked up over it :)

Re: Linux 2.4.20-pre1

[Alan Cox]

On Tue, 2002-08-06 at 18:17, Jean Tourrilhes wrote:
> 	Yep, tons of these :
> -----------------------------------------------
> -        IRDA_DEBUG(4, __FUNCTION__ "(), speed=%d (was %d)\n", speed, 
> -		   self->speed);
> +        IRDA_DEBUG(4, "%s(), speed=%d (was %d)\n", __FUNCTION__,
> +        	speed, self->speed);
> -----------------------------------------------
> 	Between this and fixing a Oops or Deadlock, I'll take the
> second any day.

I'd prefer to be able to read the errors too but yes.

> Alan if anything was pending, so that I could avoid wasting my time
> and instead wait for the next release doing something else.
> 	I guess it's too late, I already wasted my afternoon.

By the time you asked I'd sent them

> 	The second thing that bugs me is that because those patches
> pass behind my back, they won't get applied to *both* 2.4.X and
> 2.5.X. Because of that, keeping 2.4.X and 2.5.X in synch is an
> exercise in futility.

I sent them to the maintainer. 


IRDA SUBSYSTEM
P:      Dag Brattli
M:      Dag Brattli <dag@brattli.net>
L:      linux-irda@pasta.cs.uit.no
W:      http://irda.sourceforge.net/
S:      Maintained


If thats wrong, then thats why you never found out.

Linux 2.4.20-pre1

[Marcelo Tosatti]

So here goes -pre1, with a big -ac and x86-64 merges, plus other smaller
stuff.

2.4.20 will be a much faster release cycle than 2.4.19 was.




Summary of changes from v2.4.19 to v2.4.20-pre1
============================================

<jejb@mulgrave.(none)> (02/03/16 1.159.1.1)
	53c700

<achirica@ttd.net> (02/05/31 1.445.1.13)
	airo wireless net driver update:

<rob@osinvestor.com> (02/06/05 1.537.4.1)
	Sparc32 code cleanups.

<rob@osinvestor.com> (02/06/05 1.537.4.2)
	Sparc32 code cleanups.

<davem@nuts.ninka.net> (02/06/07 1.537.4.3)
	Sparc: Fix copy_{to,from}_user return value handling.

<davem@nuts.ninka.net> (02/06/07 1.537.4.4)
	Sparc64: readv/writev SuS compliance fix for sparc32 compat.

<baccala@vger.freesoft.org> (02/06/07 1.537.4.5)
	DBRI driver: Add T7903 doc URL.

<kanojsarcar@yahoo.com> (02/06/07 1.537.4.6)
	Sparc64: Fix module symbols when stack debugging is on.

<jejb@mulgrave.(none)> (02/06/09 1.159.1.2)
	[SCSI 53c700] bux fix in tag starvation, cosmetic cleanup of set_depth

<jejb@mulgrave.(none)> (02/06/09 1.159.1.3)
	[SCSI 53c700] update version to 2.8

<ak@muc.de> (02/06/12 1.537.1.8)
	RTNETLINK: Allow non-root to receive.

<davem@nuts.ninka.net> (02/06/12 1.537.1.9)
	MAINTAINERS: Remove Andi from networking as per his request.

<rusty@rustcorp.com.au> (02/06/12 1.537.1.10)
	ipv4/route.c: Cleanup ip_rt_acct_read

<jgarzik@rum.normnet.org> (02/06/14 1.537.7.1)
	net driver 8139cp updates:

<wstinson@infonie.fr> (02/06/14 1.537.9.1)
	[janitor] update the isicom.c multiport serial driver to

<wstinson@infonie.fr> (02/06/14 1.537.7.3)
	[janitor] update the ray_cs.c PCMCIA client driver for the Raylink wireless LAN card

<wstinson@infonie.fr> (02/06/14 1.537.7.4)
	[janitor] update the ni65 network driver to

<wstinson@infonie.fr> (02/06/14 1.537.7.5)
	[janitor] update the sdlamain Multiprotocol WAN Link Driver to

<wstinson@infonie.fr> (02/06/14 1.537.9.2)
	[janitor] update the DAC960 Driver for Mylex DAC960/AcceleRAID/eXtremeRAID PCI RAID Controllers

<wstinson@infonie.fr> (02/06/14 1.537.7.6)
	[janitor] update the eexpress.c net driver to

<wstinson@infonie.fr> (02/06/14 1.537.7.7)
	[janitor] update the comx-hw-comx wan driver to remove call to check_region and check the status of call to

<wstinson@infonie.fr> (02/06/14 1.537.7.8)
	[janitor] update the eepro Intel EtherExpress Pro/10 device driver to

<wstinson@infonie.fr> (02/06/14 1.537.7.9)
	[janitor] update the atarilance Ethernet driver for VME Lance cards on the Atari to check the result of request_irq and exit in case of error.

<wstinson@infonie.fr> (02/06/14 1.537.7.10)
	[janitor] update the yam hamradio driver to

<jgarzik@rum.normnet.org> (02/06/14 1.537.10.1)
	Support dumping NIC-specific stats in 8139cp net driver

<jes@wildopensource.com> (02/06/15 1.537.1.11)
	Tigon3: Use unsigned type for dest_idx_unmasked in tg3_recycle_rx.

<jes@wildopensource.com> (02/06/15 1.537.1.12)
	Tigon3: MAX_WAIT_CNT is too large.

<edward_peng@dlink.com.tw> (02/06/15 1.537.7.12)
	dl2k gige net driver updates:

<michaelw@foldr.org> (02/06/17 1.537.4.7)
	sparc64: Use SUNW,power-off to power off some Ultra systems.

<ctindel@cup.hp.com> (02/06/18 1.537.1.13)
	drivers/net/bonding.c: Check ethtool then mii ioctl to determine link status.

<davem@nuts.ninka.net> (02/06/18 1.537.1.14)
	NET: Backport 2.5.x NAPI infrastructure to 2.4.x

<davem@nuts.ninka.net> (02/06/19 1.537.1.15)
	Tigon3: On 32-bit just wrap low 32bits of stats if we overflow.

<jgarzik@mandrakesoft.com> (02/06/20 1.537.12.3)
	Add register dumping and NIC-specific stats to 8139too net driver

<jgarzik@mandrakesoft.com> (02/06/20 1.537.12.4)
	Fix 8139too net driver register dump

<wa@almesberger.net> (02/06/21 1.537.1.16)
	include/net/dsfield.h: Remove dead code.

<jmorris@intercode.com.au> (02/06/25 1.537.1.17)
	NETLINK: Add unicast release notifier.

<davem@nuts.ninka.net> (02/06/25 1.537.1.18)
	SunHME: Register IRQ with netdev->name as string.

<davem@nuts.ninka.net> (02/07/11 1.537.1.19)
	Add netif_receive_skb-like interface for VLAN hw accel.

<davem@nuts.ninka.net> (02/07/11 1.537.1.20)
	Tigon3: Add NAPI support.

<kiran@in.ibm.com> (02/07/12 1.537.1.21)
	net/core/dst.c: dst_total only needs to exist if RT_CACHE_DEBUG >= 2

<rml@tech9.net> (02/07/15 1.537.1.22)
	net/socket.c: Kill memory leak in sock_fasync

<uzi@uzix.org> (02/07/16 1.537.4.8)
	SunHME: Make module license visible when not-PCI.

<davem@nuts.ninka.net> (02/07/16 1.537.4.9)
	arch/sparc64/defconfig: Update.

<robert.olsson@data.slu.se> (02/07/18 1.537.1.23)
	PKTGEN: Updates to version 1.2, work mostly from Ben Greear.

<davem@nuts.ninka.net> (02/07/18 1.537.1.24)
	PKTGEN: Use htonl instead of __constant_htonl.

<kuznet@ms2.inr.ac.ru> (02/07/18 1.537.1.25)
	PKT SCHED: Add HTB scheduler by Martin Devera.

<ecd@skynet.be> (02/07/18 1.537.4.10)
	SPARC64: Fix bugs in ioctl32 registration.

<szepe@pinerecords.com> (02/07/18 1.537.4.11)
	SPARC: Dynamically size SRMMU nocache page pool.

<ebrower@resilience.com> (02/07/19 1.537.1.26)
	SK98LIN: Fix oops in procfs handling if no cards probed.

<rob@osinvestor.com> (02/07/19 1.537.4.12)
	SPARC: Minor header file cleanups.

<rob@osinvestor.com> (02/07/19 1.537.4.13)
	floppy.h: Remove unused empty virtual_dma_init.

<robert.olsson@data.slu.se> (02/07/19 1.537.1.27)
	PKTGEN: Update documentation.

<davem@nuts.ninka.net> (02/07/19 1.537.1.28)
	TIGON3: Finish up NAPI implementation.

<davem@nuts.ninka.net> (02/07/19 1.537.1.29)
	PKTGEN: u64 is not necessarily a long long

<davem@nuts.ninka.net> (02/07/19 1.537.1.30)
	HTB PKTSCHED: u64 is not necessarily a long long

<davem@nuts.ninka.net> (02/07/19 1.537.1.31)
	PKTGEN: Fix need_resched for 2.4.x, more u64 printf fixes.

<davem@nuts.ninka.net> (02/07/19 1.537.1.32)
	PKTGEN: More need_resched 2.4.x fixes

<davem@nuts.ninka.net> (02/07/22 1.537.1.33)
	net/ipv4/route.c: Handle large offsets properly in procfs read operation.

<davem@nuts.ninka.net> (02/07/22 1.537.4.14)
	drivers/sbus/char/openprom.c: Verify user len in copyin_string.

<rob@osinvestor.com> (02/07/22 1.537.4.15)
	arch/sparc/config.in: Remove commented out LVM bits.

<davem@nuts.ninka.net> (02/07/30 1.537.4.16)
	Openprom: Cast nagative tests properly.

<davem@nuts.ninka.net> (02/07/30 1.537.4.17)
	OpenPROM: Cast to ssize_t not int.

<davem@nuts.ninka.net> (02/07/30 1.537.4.18)
	OpenPROM: Kill len check, it is pointless.

<davem@nuts.ninka.net> (02/07/31 1.537.4.19)
	OpenPROM: Sigh, put the length overflow check back it is needed.

<rusty@rustcorp.com.au> (02/08/02 1.582.2.84)
	[PATCH] wan/sdla_chdlc.c oops fix

<mauelshagen@sistina.com> (02/08/02 1.582.2.85)
	[PATCH] LVM 1.0.5 driver update for 2.4.19-rc3

<hch@lst.de> (02/08/02 1.582.2.86)
	[PATCH] remove unused label in fs/dnotify.c

<rusty@rustcorp.com.au> (02/08/02 1.582.2.87)
	[PATCH] ip_nat_core.c - fix compiler warning

<rusty@rustcorp.com.au> (02/08/02 1.582.2.88)
	[PATCH] 3c509.c - 1_2

<rusty@rustcorp.com.au> (02/08/02 1.582.2.89)
	[PATCH] 2.4 i_size_high fixup

<rusty@rustcorp.com.au> (02/08/02 1.582.2.90)
	[PATCH] remove agpgart_be.c unused variables

<rusty@rustcorp.com.au> (02/08/02 1.582.2.91)
	[PATCH] namespace.c - compiler warning

<hch@infradead.org> (02/08/02 1.582.2.92)
	[PATCH] small inline assembly fix for gcc 3.1 (ffs)

<szepe@pinerecords.com> (02/08/02 1.582.2.93)
	[PATCH] reserve nocache based on RAM size

<flo@rfc822.org> (02/08/02 1.582.2.94)
	[PATCH] 2.4.19-rc5 cyclades.c one liner

<garloff@suse.de> (02/08/02 1.582.2.95)
	[PATCH] IDE: memset kmalloced gendisk structures

<agrover@groveronline.com> (02/08/02 1.582.2.96)
	[PATCH] Put Intel cache-detection descriptors in a table

<hch@infradead.org> (02/08/02 1.582.2.97)
	[PATCH] proper boot-time messages for P4 Xeon

<bunk@fs.tum.de> (02/08/02 1.582.2.98)
	[PATCH] document that cmd64x.c supports the CMD649 and CMD680

<jo-lkml@suckfuell.net> (02/08/02 1.592)
	[PATCH] Correct locking on IO stats accounting

<willy@w.ods.org> (02/08/03 1.594)
	[PATCH] Reorder TOSHIBA TC35815 in Config.in

<rob@osinvestor.com> (02/08/03 1.595)
	[PATCH] watchdog flags

<kaos@ocs.com.au> (02/08/03 1.596)
	[PATCH] 2.4.19 include/linux/vmalloc.h for highmem

<marcel@holtmann.org> (02/08/03 1.596.2.1)
	[PATCH] Bluetooth Subsystem PC Card drivers update

<felipewd@terra.com.br> (02/08/03 1.596.3.1)
	Add Wake-On-Lan support to 8139cp net driver

<jgarzik@mandrakesoft.com> (02/08/03 1.596.3.2)
	Temporarily disable MTU-change-while-active support in 8139cp

<felipewd@terra.com.br> (02/08/03 1.596.3.3)
	Update 8139cp net driver to enable legacy Rx/TX command register

<felipewd@terra.com.br> (02/08/03 1.596.3.4)
	Add suspend/resume support to 8139cp net driver

<davidm@hpl.hp.com> (02/08/03 1.596.3.5)
	Update eepro100 net drvr to enable rx DMA without causing

<jgarzik@mandrakesoft.com> (02/08/03 1.596.3.6)
	Add Intel e100 net driver.

<jgarzik@mandrakesoft.com> (02/08/03 1.596.3.7)
	Add e1000 gige net driver.

<jgarzik@mandrakesoft.com> (02/08/03 1.596.3.8)
	Move e100 net driver after eepro100, in kernel image link order.

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.601)
	[PATCH] PATCH: 2.4.20-pre1 - parisc specific include files

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.602)
	[PATCH] PATCH: 2.4.20pre1 - parisc gsc bus

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.603)
	[PATCH] PATCH: 2.4.20-pre1 HP HIL drivers

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.604)
	[PATCH] PATCH: Update the MPT fusion drivers to the vendors latest

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.605)
	[PATCH] PATCH: 2.4/2.5 - Fix endianness on 3c503

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.606)
	[PATCH] PATCH: remove unneeded parisc magic in acenic

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.607)
	[PATCH] PATCH: depca update

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.608)
	[PATCH] PATCH: 2.4/2.5 - Fix traps on alpha when using ewrk3

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.609)
	[PATCH] PATCH: fix gcc warnings in baycom_epp

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.610)
	[PATCH] PATCH: 2.4/2.5 Fix endianness in hp-plus

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.611)
	[PATCH] PATCH: fix multiple gcc 3.1 warnings in irda

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.612)
	[PATCH] PATCH: 2.4/2.5 fix endianness on smc boards

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.613)
	[PATCH] PATCH: 2.4/2.5 fix endianness in wd.c

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.614)
	[PATCH] PATCH: 2.4 - move nubus to static inline

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.615)
	[PATCH] PATCH: 2.4 update gsc parallel port - from maintainer

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.616)
	[PATCH] PATCH: update the aacraid driver

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.617)
	[PATCH] PATCH: fix aic7xxx build when PCI=n

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.618)
	[PATCH] PATCH: eata scsi - update from author

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.619)
	[PATCH] PATCH: fix typo in ncr53c8xx

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.620)
	[PATCH] PATCH: u14-34f scsi driver update from author

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.621)
	[PATCH] PATCH: driver for harmony audio

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.622)
	[PATCH] PATCH: trident audio updates

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.623)
	[PATCH] PATCH: fix undefined C in ixj driver

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.624)
	[PATCH] PATCH: fix gcc 3.1 warnings

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.625)
	[PATCH] PATCH: update sti frame buffer

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.626)
	[PATCH] PATCH: pull the rest of sti into a subdirectory and update it

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.627)
	[PATCH] PATCH: Beos file systems (befs)

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.628)
	[PATCH] PATCH: SOM binary load (parisc specific)

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.629)
	[PATCH] PATCH: Add EFI partition support

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.630)
	[PATCH] PATCH: more hp specific include files

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.631)
	[PATCH] PATCH: Fix gcc 3.1 warnings in vlan

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.632)
	[PATCH] PATCH: fix formatting

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.633)
	[PATCH] PATCH: gcc 3.1 warning fixes for generic_serial

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.634)
	[PATCH] PATCH: HP specific drivers

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.635)
	[PATCH] PATCH: fix compiler warning in mxser

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.636)
	[PATCH] PATCH: (resend for 2.4.20-pre1 as asked) synclink pcmcia

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.637)
	[PATCH] PATCH: PDC (parisc bios) console driver

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.638)
	[PATCH] PATCH: fix compiler warnings

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.639)
	[PATCH] PATCH: fix stallion failing to load

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.640)
	[PATCH] PATCH: fix sx driver compile warnings

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.641)
	[PATCH] PATCH: fix standards compliance bugs in the tty layer

<alan@irongate.swansea.linux.org.uk> (02/08/05 1.642)
	[PATCH] PATCH: clean up umem further

<marcelo@plucky.distro.conectiva> (02/08/05 1.643)
	Changed makefile to .20-pre1

<marcelo@plucky.distro.conectiva> (02/08/05 1.644)
	Import patch revert-acenic-change.patch

<ak@muc.de> (02/08/05 1.645)
	[PATCH] AMD 8111 PCI IDS

<ak@muc.de> (02/08/05 1.646)
	[PATCH] AMD 8111 sound support

<ak@muc.de> (02/08/05 1.647)
	[PATCH] x86-64 auto_fs support

<ak@muc.de> (02/08/05 1.648)
	[PATCH] bluetooth flags warning fixes

<ak@muc.de> (02/08/05 1.649)
	[PATCH] cciss interrupt flags warnings

<ak@muc.de> (02/08/05 1.650)
	[PATCH] CONFIG_ISA for drivers/char

<ak@muc.de> (02/08/05 1.651)
	[PATCH] CONFIG_ISA for IDE

<ak@muc.de> (02/08/05 1.652)
	[PATCH] CONFIG_ISA for radio drivers

<ak@muc.de> (02/08/05 1.653)
	[PATCH] Configuration fixes for net drivers

<ak@muc.de> (02/08/05 1.654)
	[PATCH] DRM 64bit fixes

<ak@muc.de> (02/08/05 1.655)
	[PATCH] Early console support for x86-64

<ak@muc.de> (02/08/05 1.656)
	[PATCH] x86-64 ELF format name

<ak@muc.de> (02/08/05 1.657)
	[PATCH] Ftape 64bit/x86-64 fixes

<ak@muc.de> (02/08/05 1.658)
	[PATCH] CONFIG_ISA for i386

<ak@muc.de> (02/08/05 1.659)
	[PATCH] Interrupt flags fixes for IEEE1394

<ak@muc.de> (02/08/05 1.660)
	[PATCH] x86-64 support in ipc/

<ak@muc.de> (02/08/05 1.661)
	[PATCH] 64bit fixes for drivers/isdn

<ak@muc.de> (02/08/05 1.662)
	[PATCH] 64bit fixes for the megaraid driver

<ak@muc.de> (02/08/05 1.663)
	[PATCH] paride interrupt flags fixes

<ak@muc.de> (02/08/05 1.664)
	[PATCH] 64bit warning fixes for PCI

<ak@muc.de> (02/08/05 1.665)
	[PATCH] synclink interrupt flag fixes

<ak@muc.de> (02/08/05 1.666)
	[PATCH] 64bit fixes for drivers/video

<ak@muc.de> (02/08/05 1.667)
	[PATCH] vsyscall/HPET support for x86-64

<ak@muc.de> (02/08/05 1.668)
	[PATCH] 64bit WAN driver fixes

<ak@muc.de> (02/08/05 1.669)
	[PATCH] wavelan 64bit warning

<ak@muc.de> (02/08/05 1.670)
	[PATCH] x86-64 core changes

<pkot@linuxnews.pl> (02/08/05 1.671)
	[PATCH] remove the warning from include/linux/dcache.h

<ak@muc.de> (02/08/05 1.673)
	[PATCH] 64bit dpt driver fixes

<elenstev@mesatop.com> (02/08/05 1.674)
	[PATCH] 2.4.19,

<maxk@qualcomm.com> (02/08/05 1.675)
	[PATCH] core fixes

<maxk@qualcomm.com> (02/08/05 1.676)
	[PATCH] L2CAP fixes

<maxk@qualcomm.com> (02/08/05 1.677)
	[PATCH] SCO fixes

<maxk@qualcomm.com> (02/08/05 1.678)
	[PATCH] HCI USB driver update

<maxk@qualcomm.com> (02/08/05 1.679)
	[PATCH] BNEP support

<Kai.Makisara@kolumbus.fi> (02/08/05 1.680)
	[PATCH] SCSI tape patch for 2.4.19

<marcelo@plucky.distro.conectiva> (02/08/05 1.681)
	Remove NAPI for now

Re: Linux 2.4.20-pre1

[Ben Greear]

Marcelo Tosatti wrote:
> So here goes -pre1, with a big -ac and x86-64 merges, plus other smaller
> stuff.
> 
> 2.4.20 will be a much faster release cycle than 2.4.19 was.

Two questions:  I see change logs about NAPI going in, and then
NAPI being removed.  I assume it is removed...but maybe it will
be back soon?

Second:  Where is the patch?  I looked on kernel.org and didn't
find it.  If it's going to be there shortly, that's fine, I'll
keep checking back.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: Linux 2.4.20-pre1

[Marcelo Tosatti]

On Mon, 5 Aug 2002, Ben Greear wrote:

> Marcelo Tosatti wrote:
> > So here goes -pre1, with a big -ac and x86-64 merges, plus other smaller
> > stuff.
> >
> > 2.4.20 will be a much faster release cycle than 2.4.19 was.
>
> Two questions:  I see change logs about NAPI going in, and then
> NAPI being removed.  I assume it is removed...but maybe it will
> be back soon?

I want arguments from Davem to include NAPI. Changing the drivers is a
reason for me to _not_ want it in.

But lets see if Davem can convince me ;)

> Second:  Where is the patch?  I looked on kernel.org and didn't
> find it.  If it's going to be there shortly, that's fine, I'll
> keep checking back.

Maybe at davem's CVS repo?

Re: Linux 2.4.20-pre1

[David S. Miller]

   From: Marcelo Tosatti <marcelo@conectiva.com.br>
   Date: Tue, 6 Aug 2002 08:32:59 -0300 (BRT)
   
   > Second:  Where is the patch?  I looked on kernel.org and didn't
   > find it.  If it's going to be there shortly, that's fine, I'll
   > keep checking back.
   
   Maybe at davem's CVS repo?

I don't use CVS anymore...

Re: Linux 2.4.20-pre1

[Ben Greear]

Marcelo Tosatti wrote:
> 
> On Mon, 5 Aug 2002, Ben Greear wrote:
> 
> 
>>Marcelo Tosatti wrote:
>>
>>>So here goes -pre1, with a big -ac and x86-64 merges, plus other smaller
>>>stuff.
>>>
>>>2.4.20 will be a much faster release cycle than 2.4.19 was.
>>
>>Two questions:  I see change logs about NAPI going in, and then
>>NAPI being removed.  I assume it is removed...but maybe it will
>>be back soon?
> 
> 
> I want arguments from Davem to include NAPI. Changing the drivers is a
> reason for me to _not_ want it in.
> 
> But lets see if Davem can convince me ;)

Well, I hope he does, and I hope it really works :)

The patch I was looking for was the pre-patch you put out.
I see it's on kernel.org now, so no problem there.

Ben
> 
> 
>>Second:  Where is the patch?  I looked on kernel.org and didn't
>>find it.  If it's going to be there shortly, that's fine, I'll
>>keep checking back.
> 
> 
> Maybe at davem's CVS repo?
> 


-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: Linux 2.4.20-pre1

[Jason Lunz]

Will you consider using one of those perl scripts to condense the
changelogs a little bit?

Jason

Re: Linux 2.4.20-pre1

[CaT]

On Tue, Aug 06, 2002 at 10:58:03AM -0400, Jason Lunz wrote:
> Will you consider using one of those perl scripts to condense the
> changelogs a little bit?

Please use them. -Please-...

-- 
| You wake up. The room is spinning very gently | >i
| round your head. Or at least it would be if   | You have:
| you could see it which you can't.             |   a splitting headache
|                                               |   no tea
| It is pitch black                             |

Re: Linux 2.4.20-pre1

[Adrian Bunk]

The changes to drivers/net/tg3.c in -pre1 broke the compilation:

<--  snip  -->

...
gcc -D__KERNEL__ -I/home/bunk/linux/kernel-2.4/linux-2.4.19-full/include
-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing
-fno-common -pipe -mpreferred-stack-boundary=2 -march=k6   -nostdinc -I
/usr/lib/gcc-lib/i386-linux/2.95.4/include -DKBUILD_BASENAME=tg3  -c -o
tg3.o tg3.c
In file included from tg3.c:25:
/home/bunk/linux/kernel-2.4/linux-2.4.19-full/include/linux/if_vlan.h: In
function `__vlan_hwaccel_rx':
/home/bunk/linux/kernel-2.4/linux-2.4.19-full/include/linux/if_vlan.h:186:
warning: implicit declaration of function `netif_receive_skb'
tg3.c: In function `tg3_poll':
tg3.c:1936: structure has no member named `quota'
tg3.c:1937: structure has no member named `quota'
tg3.c:1942: structure has no member named `quota'
tg3.c:1949: warning: implicit declaration of function `netif_rx_complete'
tg3.c: In function `tg3_interrupt_main_work':
tg3.c:1976: warning: implicit declaration of function
`netif_rx_schedule_prep'
tg3.c:1979: warning: implicit declaration of function
`__netif_rx_schedule'
tg3.c: In function `tg3_init_one':
tg3.c:5991: structure has no member named `poll'
tg3.c:5992: structure has no member named `weight'
make[3]: *** [tg3.o] Error 1
make[3]: Leaving directory `/home/bunk/linux/kernel-2.4/linux-2.4.19-full/drivers/net'

<--  snip  -->

cu
Adrian

-- 

You only think this is a free country. Like the US the UK spends a lot of
time explaining its a free country because its a police state.
								Alan Cox

Re: Linux 2.4.20-pre1

[David S. Miller]

   Date: Tue, 6 Aug 2002 23:05:44 +0200 (CEST)
   From: Adrian Bunk <bunk@fs.tum.de>

   The changes to drivers/net/tg3.c in -pre1 broke the compilation:
 ...
   /home/bunk/linux/kernel-2.4/linux-2.4.19-full/include/linux/if_vlan.h:186:
   warning: implicit declaration of function `netif_receive_skb'
   tg3.c: In function `tg3_poll':

Because Marcelo took the tg3 NAPI changes but not the NAPI
infrastructure. :-)

I'm hoping since he's decided to take the generic NAPI changes
this compile failure will go away in -pre2

Re: Linux 2.4.20-pre1

[J.A. Magallon]

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


On 2002.08.06 Marcelo Tosatti wrote:
>
>So here goes -pre1, with a big -ac and x86-64 merges, plus other smaller
>stuff.
>
>
><jgarzik@mandrakesoft.com> (02/08/03 1.596.3.6)
>	Add Intel e100 net driver.
>
><jgarzik@mandrakesoft.com> (02/08/03 1.596.3.7)
>	Add e1000 gige net driver.
>

Configure.help missing for those. Attached.

btw, I don't like this also, but is the official one...

-- 
J.A. Magallon             \   Software is like sex: It's better when it's free
mailto:jamagallon@able.es  \                    -- Linus Torvalds, FSF T-shirt
Linux werewolf 2.4.19-jam0, Mandrake Linux 9.0 (Cooker) for i586
gcc (GCC) 3.2 (Mandrake Linux 9.0 3.2-0.2mdk)

[-- Attachment #2: intel-eth-help.diff.gz --]
[-- Type: application/x-gzip, Size: 1475 bytes --]

Re: Linux 2.4.20-pre1

[J.A. Magallon]

On 2002.08.06 Marcelo Tosatti wrote:
>
>So here goes -pre1, with a big -ac and x86-64 merges, plus other smaller
>stuff.
>

Something is missing in the network merge:

werewolf:/usr/src/linux# grep -r netif_receive_skb *
drivers/net/tg3.c:                      netif_receive_skb(skb);
Binary file drivers/net/e1000/e1000_main.o matches
Binary file drivers/net/e1000/e1000.o matches
include/linux/if_vlan.h:        //return (polling ? netif_receive_skb(skb) : netif_rx(skb));

So I had to:

--- linux/include/linux/if_vlan.h.orig	2002-08-07 02:57:36.000000000 +0200
+++ linux/include/linux/if_vlan.h	2002-08-07 02:58:07.000000000 +0200
@@ -183,7 +183,8 @@
 		break;
 	};
 
-	return (polling ? netif_receive_skb(skb) : netif_rx(skb));
+	//return (polling ? netif_receive_skb(skb) : netif_rx(skb));
+	return netif_rx(skb);
 }
 
 static inline int vlan_hwaccel_rx(struct sk_buff *skb,

To make e1000 build. But tg3 uses n_r_skb directly, so it is not useful for
that.

-- 
J.A. Magallon             \   Software is like sex: It's better when it's free
mailto:jamagallon@able.es  \                    -- Linus Torvalds, FSF T-shirt
Linux werewolf 2.4.19-jam0, Mandrake Linux 9.0 (Cooker) for i586
gcc (GCC) 3.2 (Mandrake Linux 9.0 3.2-0.2mdk)

Re: Linux 2.4.20-pre1

[Bryan Whitehead]

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

Marcelo Tosatti wrote:
> So here goes -pre1, with a big -ac and x86-64 merges, plus other smaller
> stuff.
> 
> 2.4.20 will be a much faster release cycle than 2.4.19 was.
> 
> 

This didn't make 2.4.19. Just a spelling error. I tried the maintainer 
but got no reply...

(yea yea... i just like clean logs... ) :)

;)

-- 
Bryan Whitehead
SysAdmin - JPL - Interferometry Systems and Technology
Phone: 818 354 2903
driver@jpl.nasa.gov

[-- Attachment #2: natsemi.patch --]
[-- Type: text/plain, Size: 400 bytes --]

--- linux/drivers/net/natsemi.c.orig	Tue Aug  6 18:50:13 2002
+++ linux/drivers/net/natsemi.c	Tue Aug  6 18:50:38 2002
@@ -1685,7 +1685,7 @@
 			np->tx_config += 2;
 		if (netif_msg_tx_err(np))
 			printk(KERN_NOTICE 
-				"%s: increased Tx theshold, txcfg %#08x.\n",
+				"%s: increased Tx threshold, txcfg %#08x.\n",
 				dev->name, np->tx_config);
 		writel(np->tx_config, ioaddr + TxConfig);
 	}

Re: Linux 2.4.20-pre1

[Tim Hockin]

> This didn't make 2.4.19. Just a spelling error. I tried the maintainer 
> but got no reply...
> 
> (yea yea... i just like clean logs... ) :)
> 
> ;)

ok, ok, It's going into my bk tree...sheesh :)

Re: Linux 2.4.20-pre1

[Erik Andersen]

On Mon Aug 05, 2002 at 07:40:56PM -0300, Marcelo Tosatti wrote:
> 
> So here goes -pre1, with a big -ac and x86-64 merges, plus other smaller
> stuff.
[------------snip------------]
> <alan@irongate.swansea.linux.org.uk> (02/08/05 1.629)
> 	[PATCH] PATCH: Add EFI partition support

Needs this to compile....

--- linux/include/asm-ia64/efi.h.orig	Sun Aug 11 01:41:10 2002
+++ linux/include/asm-ia64/efi.h	Sun Aug 11 01:43:38 2002
@@ -166,6 +166,9 @@
  *  EFI Configuration Table and GUID definitions
  */
 
+#define NULL_GUID    \
+    ((efi_guid_t) { 0x00000000, 0x0000, 0x0000, { 0x00, 0x00, 0x0, 0x00, 0x00, 0x00, 0x00, 0x00 }})
+
 #define MPS_TABLE_GUID    \
     ((efi_guid_t) { 0xeb9d2d2f, 0x2d88, 0x11d3, { 0x9a, 0x16, 0x0, 0x90, 0x27, 0x3f, 0xc1, 0x4d }})
 

> <rusty@rustcorp.com.au> (02/08/02 1.582.2.91)
> 	[PATCH] namespace.c - compiler warning

This patch is wrong....

--- linux/fs/namespace.c.orig	Sun Aug 11 01:50:52 2002
+++ linux/fs/namespace.c	Sun Aug 11 01:51:04 2002
@@ -29,8 +29,6 @@
 static int hash_mask, hash_bits;
 static kmem_cache_t *mnt_cache; 
 
-extern void init_rootfs(void);
-
 static inline unsigned long hash(struct vfsmount *mnt, struct dentry *dentry)
 {
 	unsigned long tmp = ((unsigned long) mnt / L1_CACHE_BYTES);
--- linux/include/linux/namespace.h.orig	Sat Aug  3 17:14:31 2002
+++ linux/include/linux/namespace.h	Sat Aug  3 18:46:43 2002
@@ -38,5 +38,6 @@
 	atomic_inc(&namespace->count);
 }
 
+int __init init_rootfs(void);
 #endif
 #endif


 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: Linux 2.4.20-pre1

[Christoph Hellwig]

On Sun, Aug 11, 2002 at 02:57:17AM -0600, Erik Andersen wrote:
> > 	[PATCH] namespace.c - compiler warning
> 
> This patch is wrong....

Why?

Re: Linux 2.4.20-pre1

[Erik Andersen]

On Sun Aug 11, 2002 at 10:16:17AM +0100, Christoph Hellwig wrote:
> On Sun, Aug 11, 2002 at 02:57:17AM -0600, Erik Andersen wrote:
> > > 	[PATCH] namespace.c - compiler warning
> > 
> > This patch is wrong....
> 
> Why?

Because it adds function prototype that doesn't match the
actual function....  

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: Linux 2.4.20-pre1

[Erik Andersen]

On Sun Aug 11, 2002 at 10:16:17AM +0100, Christoph Hellwig wrote:
> On Sun, Aug 11, 2002 at 02:57:17AM -0600, Erik Andersen wrote:
> > > 	[PATCH] namespace.c - compiler warning
> > 
> > This patch is wrong....
> 
> Why?

I guess it would be more clear if I had said that namespace.c
in 2.4.20-pre1 was broken my the above mentioned patch, and
my patch fixes the problem...

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: Linux 2.4.20-pre1

[Alan Cox]

On Sun, 2002-08-11 at 09:57, Erik Andersen wrote:
> On Mon Aug 05, 2002 at 07:40:56PM -0300, Marcelo Tosatti wrote:
> > 
> > So here goes -pre1, with a big -ac and x86-64 merges, plus other smaller
> > stuff.
> [------------snip------------]
> > <alan@irongate.swansea.linux.org.uk> (02/08/05 1.629)
> > 	[PATCH] PATCH: Add EFI partition support
> 
> Needs this to compile....
> 
> --- linux/include/asm-ia64/efi.h.orig	Sun Aug 11 01:41:10 2002
> +++ linux/include/asm-ia64/efi.h	Sun Aug 11 01:43:38 2002
> @@ -166,6 +166,9 @@
>   *  EFI Configuration Table and GUID definitions
>   */
>  
> +#define NULL_GUID    \
> +    ((efi_guid_t) { 0x00000000, 0x0000, 0x0000, { 0x00, 0x00, 0x0, 0x00, 0x00, 0x00, 0x00, 0x00 }})
> +

Not a good plan. EFI can be used on non ia64 so NULL_GUID belongs
somewhere else

Re: Linux 2.4.20-pre1

[Erik Andersen]

On Sun Aug 11, 2002 at 08:46:19PM +0100, Alan Cox wrote:
> On Sun, 2002-08-11 at 09:57, Erik Andersen wrote:
> > On Mon Aug 05, 2002 at 07:40:56PM -0300, Marcelo Tosatti wrote:
> > > 
> > > So here goes -pre1, with a big -ac and x86-64 merges, plus other smaller
> > > stuff.
> > [------------snip------------]
> > > <alan@irongate.swansea.linux.org.uk> (02/08/05 1.629)
> > > 	[PATCH] PATCH: Add EFI partition support
> > 
> > Needs this to compile....
> > 
> > --- linux/include/asm-ia64/efi.h.orig	Sun Aug 11 01:41:10 2002
> > +++ linux/include/asm-ia64/efi.h	Sun Aug 11 01:43:38 2002
> > @@ -166,6 +166,9 @@
> >   *  EFI Configuration Table and GUID definitions
> >   */
> >  
> > +#define NULL_GUID    \
> > +    ((efi_guid_t) { 0x00000000, 0x0000, 0x0000, { 0x00, 0x00, 0x0, 0x00, 0x00, 0x00, 0x00, 0x00 }})
> > +
> 
> Not a good plan. EFI can be used on non ia64 so NULL_GUID belongs
> somewhere else


I know.  But if you look at the source, the generic stuff is
directly including asm-ia64/efi.h, so this makes it compile.  I
agree having the generic stuff include asm-ia64 code is really
stupid, but changing that seemed far more invasive and frankly, I
don't even know what an "EFI" is, so I didn't want to mess with
it beyond making it compile per how it is currently doing things,

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: Linux 2.4.20-pre1

[Paul P Komkoff Jr]

Replying to Alan Cox:
> Not a good plan. EFI can be used on non ia64 so NULL_GUID belongs
> somewhere else

maybe but even without NULL_GUID I still need to add asm-ia64 to
KBUILD_INCLUDE_DIRS while trying to kbuild-25ify -ac (and marcelo now)

hint-hint: maybe it IS worth moving to generic include ?

hmm

-- 
Paul P 'Stingray' Komkoff 'Greatest' Jr /// (icq)23200764 /// (http)stingr.net
  When you're invisible, the only one really watching you is you (my keychain)

Re: Linux 2.4.20-pre1

[Erik Andersen]

On Mon Aug 05, 2002 at 07:40:56PM -0300, Marcelo Tosatti wrote:
> <achirica@ttd.net> (02/05/31 1.445.1.13)
> 	airo wireless net driver update:

Doesn't this make more sense?

--- linux/drivers/net/wireless/airo.c.orig	Sun Aug 11 03:59:28 2002
+++ linux/drivers/net/wireless/airo.c	Sun Aug 11 03:59:46 2002
@@ -191,12 +191,6 @@
 #ifndef RUN_AT
 #define RUN_AT(x) (jiffies+(x))
 #endif
-#ifndef PDE
-static inline struct proc_dir_entry *PDE(const struct inode *inode)
-{
-	return inode->u.generic_ip;
-}
-#endif
 
 
 /* These variables are for insmod, since it seems that the rates

diff -urN linux-2.4.19.orig/include/linux/proc_fs.h linux-2.4.19/include/linux/proc_fs.h
--- linux-2.4.19.orig/include/linux/proc_fs.h	Fri Aug  2 18:39:45 2002
+++ linux-2.4.19/include/linux/proc_fs.h	Sun Aug 11 00:23:55 2002
@@ -209,4 +209,9 @@
 
 #endif /* CONFIG_PROC_FS */
 
+static inline struct proc_dir_entry *PDE(const struct inode *inode)
+{
+	return (struct proc_dir_entry *)inode->u.generic_ip;
+}
+

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: Linux 2.4.20-pre1

[Adrian Bunk]

On Mon, 5 Aug 2002, Marcelo Tosatti wrote:

>...
> Summary of changes from v2.4.19 to v2.4.20-pre1
> ============================================
>...
> <ak@muc.de> (02/08/05 1.657)
> 	[PATCH] Ftape 64bit/x86-64 fixes
>...

This broke the modular building of ftape. In -pre3:

<--  snip  -->

...
depmod: *** Unresolved symbols in
/lib/modules/2.4.20-pre3/kernel/drivers/char/ftape/lowlevel/ftape.o
depmod:         i8253_lock
...

<--  snip  -->


Alan made the following patch to fix it (already in -ac):


--- linux.20pre2/arch/i386/kernel/time.c	2002-08-13 13:58:33.000000000 +0100
+++ linux.20pre2-ac3/arch/i386/kernel/time.c	2002-08-12 15:17:04.000000000 +0100
@@ -31,6 +31,7 @@
  */

 #include <linux/errno.h>
+#include <linux/module.h>
 #include <linux/sched.h>
 #include <linux/kernel.h>
 #include <linux/param.h>
@@ -116,6 +117,8 @@

 spinlock_t i8253_lock = SPIN_LOCK_UNLOCKED;

+EXPORT_SYMBOL(i8253_lock);
+
 extern spinlock_t i8259A_lock;

 #ifndef CONFIG_X86_TSC



cu
Adrian