Re: [kbuild-devel] Re: CML1 cleanup patch

Re: [kbuild-devel] Re: CML1 cleanup patch

[Michael Elizabeth Chastain]

Eric Raymond writes:
> (1) 19 of the 39 changes fix things that are outright bugs even in CML1.
>     These should not be allowed to persist in the stable branch.

I think that things that are bugs in CML1, on its own terms, are
worth fixing in 2.4.

Michael

Re: CML1 cleanup patch

[Eric S. Raymond]

Jeff Garzik <jgarzik@mandrakesoft.com>:
> FWIW I am opposed to any large-scale cleanup of the configuration
> language and/or identifiers in -any- 2.4.x series kernel.

This is tweaking 39 symbols out of 1831, hardly large-scale.  These
irregularities in the namespace cause trouble out of all proportion to
their size, is my problem.  If you knew what I've been through trying
to write analysis tools...*shudder*...
 
> Not only C code but installer utilities are affected by changes in the
> CONFIG_xxx identifiers.  If we change that namespace, we are changing
> part of the API that is exported to drivers.  Definitely not 2.4.x
> stuff.

My patch fixes those installer utilities.  All three of them.  And no driver
code is or possibly could be broken by it, that's a red herring.  *No
object code will change as a result of this patch*.
 
> If we are moving to CML2 in 2.5, I see no point in big CML1 cleanups.

Yes, I know, that's what I said about Peter's DERIVED patch a week ago.
You notice *he* ain't bitching about this one?

I want this in before the 2.5 fork for several reasons:

(1) 19 of the 39 changes fix things that are outright bugs even in CML1.
    These should not be allowed to persist in the stable branch.

(2) I want to finish my analysis tools and do some really thorough
    consistency and correctness checking before the stable branch
    separates.  Alan will thank me for this later.

(2) If we do adopt CML2, having these changes in will make it *far* 
    easier to contemplate back-porting it to 2.4.x later on.

The present configuration system is a mess, everybody agrees on that.
I'm trying to clean it up, and it's a tedious and grubby enough job
even with the full cooperation of the kbuild team.  Jeff, would you
please support this instead of obstructing it?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

  "You have taught us much. Come with us and join the movement."
  "This movement of yours, does it have slogans?" inquired the Chink.
  "Right on!" they cried. And they quoted him some.
  "Your movement, does it have a flag?" asked the Chink.
  "You bet!" and they described their emblem.
  "And does your movement have leaders?"
  "Great leaders."
  "Then shove it up your butts," said the Chink. "I have taught you nothing."

	-- Tom Robbins, "Even Cowgirls Get The Blues"

Re: [kbuild-devel] Re: CML1 cleanup patch

[Keith Owens]

On Mon, 26 Mar 2001 02:09:02 -0500, 
"Eric S. Raymond" <esr@thyrsus.com> wrote:
>Jeff Garzik <jgarzik@mandrakesoft.com>:
>> If we are moving to CML2 in 2.5, I see no point in big CML1 cleanups.
>
>Yes, I know, that's what I said about Peter's DERIVED patch a week ago.

Hey, that was my DERIVED patch, not Peter's.  Point the blame where it
is due, even I think that my patch was a bad idea.  -ENOTENOUGHCOFFEE.

The 20 cris variables must be renamed to CONFIG_xxx, otherwise make dep
will not find them and config changes will only cause partial
recompiles - or do the cris people like inconsistent kernels?

Correcting the two old names is obviously the right thing to do.

That just leaves the 17 names of the form CONFIG_[0-9]*.  Only the 8139
is likely to affect outside the kernel and the argument that renaming
config options might affect external packages does not hold.  The
recent aic7xxx change broke pcmcia on 2.2 kernels but we can work round
it.

Re: [kbuild-devel] Re: CML1 cleanup patch

[Jeff Garzik]

Keith Owens wrote:
> That just leaves the 17 names of the form CONFIG_[0-9]*.  Only the 8139
> is likely to affect outside the kernel and the argument that renaming
> config options might affect external packages does not hold.  The
> recent aic7xxx change broke pcmcia on 2.2 kernels but we can work round
> it.

There is no good reason to restrict the CML2 identifier namespace.

This is a policy change not a cleanup.

-- 
Jeff Garzik       | May you have warm words on a cold evening,
Building 1024     | a full moon on a dark night,
MandrakeSoft      | and a smooth road all the way to your door.

Re: [kbuild-devel] Re: CML1 cleanup patch

[Eric S. Raymond]

Jeff Garzik <jgarzik@mandrakesoft.com>:
> There is no good reason to restrict the CML2 identifier namespace.

I've already listed a couple of good reasons.  As Peter said, maintanicus 
selector est.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

No one who's seen it in action can say the phrase "government help" without
either laughing or crying.

Re: CML1 cleanup patch

[Eric S. Raymond]

Peter Samuelson <peter@cadcamlab.org>:
> > CONFIG_8139TOO			CONFIG_RTL8139TOO
> > CONFIG_8139TOO_PIO		CONFIG_RTL8139TOO_PIO
> > CONFIG_8139TOO_TUNE_TWISTER	CONFIG_RTL8139TOO_TUNE_TWISTER
> 
> The -TOO suffix was to distinguish between this and the former 8139
> driver, as the two coexisted in 2.2 and 2.3.  As the old driver has
> been dropped from 2.4, I propose likewise dropping the -TOO.

I'm preparing an updated version of the patch for 2.4.3-pre8.  I'll
incorporate this change.
 
> Oh, BTW -- an alternate approach to making the kernel tree compatible
> with CML2 would be to make CML2 compatible with the kernel tree.
> Define a character (say '%') as an optional prefix for a configuration
> symbol.  This character would only be required where the symbol would
> otherwise by misparsed, as with '[0-9].*'.

I considered two workarounds:

1. Adding some cruft to the language to support this case, as you suggest.

I might have gone this route, until I tripped over the two bugs and
the bad config symbols in the CRIS port tree.  That meant there was
going to have to be a cleanup patch anyway, so why not fix those 20 
symbols (out of 1831) rather than grubbifying the language?

2. Hacking the CML2 lexical analyzer to handle this case.

I could have done this, allowing tokens to be recognized as numeric only
if all chars are digits.  I didn't, for two reasons: (1) Lexical analysis
is, as it turns out, a hotspot in the CML2 compiler code -- the last thing
it needs is more overhead, and (2) interpreting symbols with leading digits
as nonnumeric tokens is just *wrong*.  Ugh.  Violates the Principle of Least
Surprise big-time.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Every election is a sort of advance auction sale of stolen goods. 
	-- H.L. Mencken 

Re: [kbuild-devel] Re: CML1 cleanup patch

[John Cowan]

esr scripsit:

> I could have done this, allowing tokens to be recognized as numeric only
> if all chars are digits.  I didn't, for two reasons: (1) Lexical analysis
> is, as it turns out, a hotspot in the CML2 compiler code -- the last thing
> it needs is more overhead, and (2) interpreting symbols with leading digits
> as nonnumeric tokens is just *wrong*.  Ugh.  Violates the Principle of Least
> Surprise big-time.

In fact this has come up before: in Usenet software, which has to differentiate
between an article and a sub-newsgroup.  An article has to have an all-numeric
name, and It Would Have Been Nice if all newsgroup names began with non-digits,
but then there was comp.bugs.4bsd.

-- 
John Cowan                                   cowan@ccil.org
One art/there is/no less/no more/All things/to do/with sparks/galore
	--Douglas Hofstadter

Re: [kbuild-devel] Re: CML1 cleanup patch

[Rik van Riel]

On Mon, 26 Mar 2001, John Cowan wrote:

> esr scripsit:
> 
> > it needs is more overhead, and (2) interpreting symbols with leading digits
> > as nonnumeric tokens is just *wrong*.  Ugh.  Violates the Principle of Least
> > Surprise big-time.
> 
> In fact this has come up before: in Usenet software, which has to
> differentiate between an article and a sub-newsgroup.  An article has
> to have an all-numeric name, and It Would Have Been Nice if all
> newsgroup names began with non-digits, but then there was
> comp.bugs.4bsd.

What's wrong with using the _file type_ for these things ?

Conversely, why can't CML2 use the CONFIG_ prefix to
determine if a symbol is a configuration option, like
we're doing now?

Please do point out if I'm missing something, but I
really fail to see what the fuss is about.

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com.br/

Re: [kbuild-devel] Re: CML1 cleanup patch

[Eric S. Raymond]

Rik van Riel <riel@conectiva.com.br>:
> What's wrong with using the _file type_ for these things ?

I don't understand that.
 
> Conversely, why can't CML2 use the CONFIG_ prefix to
> determine if a symbol is a configuration option, like
> we're doing now?

I do understand this.  Greg Banks pointed it out last night, and I'm
testing a CML2 version that implements it now.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The two pillars of `political correctness' are, 
  a) willful ignorance, and
  b) a steadfast refusal to face the truth
	-- George MacDonald Fraser

Re: [kbuild-devel] Re: CML1 cleanup patch

[Kai Henningsen]

Warning: No kernel related stuff inside.

riel@conectiva.com.br (Rik van Riel)  wrote on 26.03.01 in <Pine.LNX.4.21.0103261153510.1863-100000@imladris.rielhome.conectiva>:

> On Mon, 26 Mar 2001, John Cowan wrote:

> > In fact this has come up before: in Usenet software, which has to
> > differentiate between an article and a sub-newsgroup.  An article has
> > to have an all-numeric name, and It Would Have Been Nice if all
> > newsgroup names began with non-digits, but then there was
> > comp.bugs.4bsd.
>
> What's wrong with using the _file type_ for these things ?

Wrong problem description, really. The problem is not components starting  
with digits, the problem is all-numeric components as in alt.2600.

And the problem is that this hits a fast path in the classical news spool  
layout article create path. The code for this assumes that you have  
articles in the range X to Y, and you just got a new article, so you write  
a file called /var/spool/news/group/name/Y+1. You really do not want to  
cope with the possibility of a directory Y+1 existing in that place.

I think there are some other things that also get impacted on their fast  
path, but this is probably the most important.

And then, it's an ugly user interface: the classical spool layout does  
assume that you look at that scpool with Unix tools (like find and grep),  
not only via NNTP and the server.

MfG Kai

Re: [kbuild-devel] Re: CML1 cleanup patch

[Olaf Titz]

> And the problem is that this hits a fast path in the classical news spool
> layout article create path. The code for this assumes that you have
> articles in the range X to Y, and you just got a new article, so you write
> a file called /var/spool/news/group/name/Y+1. You really do not want to
> cope with the possibility of a directory Y+1 existing in that place.

C News did this, actually: if creat(.../name/Y+1) fails, it tries
creat(.../name/Y+2), etc. (IIRC up to 1000 times). This does not really
hurt a fast path: either you do
  sprintf(a, "...", artno);
  if (creat(a, ...)<0) {
    syslog(...);
    return FAILED;
  }
or
  while (sprintf(a, "...", artno),
         creat(a, ...)<0) {
    ++artno;
    if (++count>MAX) {
      syslog(...);
      return FAILED;
    }
  }

it's just one compare in the fast path which you need anyway.
(Initializing the counter does not _have_ to happen for each article.)

What would hurt is a stat() here, but that is not necessary. It could
be necessary in expire and/or maintenance tools, but these are not as
time-critical. The all-numerics mess up things like "find the lowest
article number" (makeactive/renumber/however it is called), in these
cases a stat is really necessary.

However I think the point is moot because the traditional spool layout
has been proven by experience to be inadequate for the job, even in
the face of more sophisticated filesystems - modern news systems need
other storage mechanisms to cope with the load anyway.

> And then, it's an ugly user interface: the classical spool layout does
> assume that you look at that scpool with Unix tools (like find and grep),
> not only via NNTP and the server.

INN needs a "storage manager grep", but that's even more off topic
here :-)

Olaf