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: [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

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

[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

[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

[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

[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: [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

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