Re: CML1 cleanup patch

Re: CML1 cleanup patch

[Peter Samuelson]

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

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].*'.

Peter

Re: CML1 cleanup patch

[Jeff Garzik]

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

It stays "8139too".  Donald Becker's rtl8139.c continues to exist
outside the kernel.  

And "rtl8139too" should have never crept into 2.2.  That needs to be
changed to "8139too."  That's what I get for saying that I don't support
2.2...

-- 
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: CML1 cleanup patch

[Jeff Garzik]

Well, bummer.  I can't seem to find Eric's message archived anywhere.

FWIW I am opposed to any large-scale cleanup of the configuration
language and/or identifiers in -any- 2.4.x series kernel.

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.

If we are moving to CML2 in 2.5, I see no point in big CML1 cleanups.

-- 
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: 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: CML1 cleanup patch

[Jeff Garzik]

"Eric S. Raymond" wrote:
> 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*...

They cause trouble for you, solely, at the moment.  Changing the CML1
namespace potentially causes trouble for many people.


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

You updated Linux-Mandrake's kernel RPM and Linux-Mandrake's installer? 
Cool!


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

Please post a patch with only these 19 changes, and make sure to CC it
to linux-kernel.

Thanks,

	Jeff


-- 
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: CML1 cleanup patch

[Eric S. Raymond]

Jeff Garzik <jgarzik@mandrakesoft.com>:
> You updated Linux-Mandrake's kernel RPM and Linux-Mandrake's installer? 
> Cool!

No, I didn't.  But I can't even imagine how these changes could break those.
 
> Please post a patch with only these 19 changes, and make sure to CC it
> to linux-kernel.

I don't think this is your decision to make, is it?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Where rights secured by the Constitution are involved, there can be no
rule making or legislation which would abrogate them.
        -- Miranda vs. Arizona, 384 US 436 p. 491

Re: CML1 cleanup patch

[Jeff Garzik]

"Eric S. Raymond" wrote:
> Jeff Garzik <jgarzik@mandrakesoft.com>:
> > You updated Linux-Mandrake's kernel RPM and Linux-Mandrake's installer?
> > Cool!

> No, I didn't.  But I can't even imagine how these changes could break those.

Our kernel build process has to look at CONFIG_xxx because we build
multiple kernels from the same base .config.


> > Please post a patch with only these 19 changes, and make sure to CC it
> > to linux-kernel.

> I don't think this is your decision to make, is it?

I have no control over what you choose to do.  It's a free 'net, and you
are free to ignore any and all suggestions.

The normal way to get patches into the kernel is to split them up.  I
just sent Linus 21 patches, which got condensed into

> -pre8:
> [...]
>   - Jeff Garzik: network driver updates, i810 rng driver, and
>     "alloc_etherdev()" network driver insert race condition fix.

Separate out your changes.  Make the maintainers aware of your changes. 
ie. if it modifies my driver's CONFIG_xxx usage or my subsystem's
Config.in, let me know.  ("me" == any maintainer)

Read Documentation/SubmittingPatches.

	Jeff


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

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

[Rik van Riel]

On Mon, 26 Mar 2001, Jeff Garzik wrote:

> Well, bummer.  I can't seem to find Eric's message archived anywhere.
> 
> FWIW I am opposed to any large-scale cleanup of the configuration
> language and/or identifiers in -any- 2.4.x series kernel.

Seconded, this is a 2.5 issue...  (IMHO, at least)

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: CML1 cleanup patch

[Eric S. Raymond]

Jeff Garzik <jgarzik@mandrakesoft.com>:
> > 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.
> 
> It stays "8139too".  Donald Becker's rtl8139.c continues to exist
> outside the kernel.  
> 
> And "rtl8139too" should have never crept into 2.2.  That needs to be
> changed to "8139too."  That's what I get for saying that I don't support
> 2.2...

Now, wait, Jeff.  I'm not attached to Peter's change, but I don't think
we can reasonably be expected to worry about every possible driver
left over from every old version of Linux when managing the
configuration-symbol namespace.  That way madness lies.

I'll cheerfully ship a supplementary patch to fix this one name later,
but we can't afford to have a wrangle over this bit of trivia delay
adoption of this one.  I have a hell of a lot of work to do for
which this is critical path.  

I left it pretty late as it is, out of hope that other people would
clean up some of the messes I noticed in the config namespace six
months ago, and they did -- but the 2.5 fork is nearly upon us and I
feel a strong need to get this in before then.

Would you and Peter please fight this out and tell me what to do in the
supplementary patch?  I don't care, as long as the result has a non-numeric
prefix -- bare "8139whatever" is out.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Sometimes it is said that man cannot be trusted with the government
of himself.  Can he, then, be trusted with the government of others?
	-- Thomas Jefferson, in his 1801 inaugural address

Re: CML1 cleanup patch

[Jeff Garzik]

"Eric S. Raymond" wrote:
> I don't care, as long as the result has a non-numeric
> prefix -- bare "8139whatever" is out.

Bullshit.  Numeric prefixes work fine in CML1.

With regards to CML2, hardware and driver filenames quite often begin
with numerals, so it is quite logical that config variables may begin
with a numeral.

You're writing CML2.  Don't create a stupid namespace with stupid
limitations.  I'm glad my filesystem and my sysctl namespace don't have
such limitations.

-- 
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: CML1 cleanup patch

[Alan Cox]

> months ago, and they did -- but the 2.5 fork is nearly upon us and I
> feel a strong need to get this in before then.

Fix it in 2.5 not before

Re: CML1 cleanup patch

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > months ago, and they did -- but the 2.5 fork is nearly upon us and I
> > feel a strong need to get this in before then.
> 
> Fix it in 2.5 not before

I hope you will reconsider after you've seen the reasons I posted in a later
message, Alan.  You're one of the people I'm tring to save a lot of hassle
for later on.  In fact, you are likely to be the largest beneficiary of
this change.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"Are we to understand," asked the judge, "that you hold your own interests
above the interests of the public?"

"I hold that such a question can never arise except in a society of cannibals."
	-- Ayn Rand

Re: CML1 cleanup patch

[Alan Cox]

> I hope you will reconsider after you've seen the reasons I posted in a later
> message, Alan.  You're one of the people I'm tring to save a lot of hassle
> for later on.  In fact, you are likely to be the largest beneficiary of
> this change.

Near term - no. I have much larger problems to worry about than config
destabilization

Re: CML1 cleanup patch

[Peter Samuelson]

  [Jeff Garzik]
> > It stays "8139too".  Donald Becker's rtl8139.c continues to exist
> > outside the kernel.

Honestly, Jeff, I don't see how it matters -- because if you are
downloading an external driver, you are not going through the config
system anyway.

But ... "maintanicus selector est" (my pseudo-Latin for "the maintainer
gets to choose") so I support your stand.

[esr]
> Now, wait, Jeff.  I'm not attached to Peter's change, but I don't
> think we can reasonably be expected to worry about every possible
> driver left over from every old version of Linux when managing the
> configuration-symbol namespace.  That way madness lies.

Eric, the issue arose because you are obliquely proposing -- nay,
insisting on -- a policy change.  CONFIG_8139TOO is a perfectly valid
preprocessor token and a perfectly valid GNU Make macro name.  It
corresponds with a source file '8139too.c' which is also perfectly
valid.

Did it never occur to you that by insisting on a policy change (and
related code changes), with no discussion, consensus or mandate, and
which fixes no current bugs ... that a few toes may feel stepped on?

The burden of proof is yours.  Why should a CML2 design decision
(stripping of CONFIG_ in the configuration files) change what seems to
be an entirely reasonable policy?  Especially since there are multiple
ways, which you have rejected, to work around the lexical problem in
CML2 itself?

Peter

Re: CML1 cleanup patch

[Eric S. Raymond]

Peter Samuelson <peter@cadcamlab.org>:
> 
>   [Jeff Garzik]
> > > It stays "8139too".  Donald Becker's rtl8139.c continues to exist
> > > outside the kernel.
> 
> Honestly, Jeff, I don't see how it matters -- because if you are
> downloading an external driver, you are not going through the config
> system anyway.
> 
> But ... "maintanicus selector est" (my pseudo-Latin for "the maintainer
> gets to choose") so I support your stand.

And that's an argument I can buy, too.  I'll restore the TOO prefix
in my change list.
 
> Eric, the issue arose because you are obliquely proposing -- nay,
> insisting on -- a policy change.  CONFIG_8139TOO is a perfectly valid
> preprocessor token and a perfectly valid GNU Make macro name.  It
> corresponds with a source file '8139too.c' which is also perfectly
> valid.
> 
> Did it never occur to you that by insisting on a policy change (and
> related code changes), with no discussion, consensus or mandate, and
> which fixes no current bugs ... that a few toes may feel stepped on?

Actually, that's not what I did.  One of the principal PPC maintainers
agreed to get the PPC numeric-prefix symbols (9 of the 20) cleaned up,
but dropped the ball.  I waited on this as long as I thought I could.

> The burden of proof is yours.  Why should a CML2 design decision
> (stripping of CONFIG_ in the configuration files) change what seems to
> be an entirely reasonable policy?  Especially since there are multiple
> ways, which you have rejected, to work around the lexical problem in
> CML2 itself?

The workarounds would be slow, or ugly, or both.  As I said -- I might
have gone with them, but there since had to be a fix patch anyway, and
I had buy-in for all but 11 of the 39 changes...
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

According to the National Crime Survey administered by the Bureau of
the Census and the National Institute of Justice, it was found that
only 12 percent of those who use a gun to resist assault are injured,
as are 17 percent of those who use a gun to resist robbery. These
percentages are 27 and 25 percent, respectively, if they passively
comply with the felon's demands. Three times as many were injured if
they used other means of resistance.
        -- G. Kleck, "Policy Lessons from Recent Gun Control Research,"

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