[lkml]   [2002]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: IO stats in /proc/partitions
On Sat, May 04, 2002 at 05:25:53PM -0400, Mark Hahn wrote:
> > I'm with Andries on this one! Linux can't survive if anyone can change it
> > and break all the supporting software in user space that reads stuff from
> there is no serious breakage issue, since the extra fields would
> not break any competent parsing code.

That is ridiculous. Parsers parse a grammar, and fails when the input doesn't
obey the grammar. Creating grammars that will satisfy *anything* that people
might think of putting into /proc files late saturday nights (take a look at
the ASCII art in /proc/mdstat for example !!) is not just something you can do
with any certainty.

You may think that you will be parsing a list of partitions - next week someone
felt that drawing a flowchart with ISO-8859-8 characters would be cooler, and
then you're stuck fixing your parser.

This was why we had a very long thread about creating an API for getting this
information out, something like kstat or pstat from some real 'NIX systems.

Let's not bring that thread up again - it's besides the point of this argument.
Read on.

> > Linux has *got* to mature to the point where the documentation is *accurate*
> > and *available* and the APIs don't wobble under the feet of their users. I
> nah. changing APIs and internals is exactly the reason Linux wins.

No. Changing APIs *when* and *where* it makes sense, is why Linux is winning.

There is a world of difference.

Disk statistics should *NOT* go into a partition-table-listing file. Put the
statistics in a file for, say, *statistics*. How hard can this be ?

It is
1) Simple
2) No more change than the original change
3) Doesn't break parsers (neither the good or the bad ones)
4) Logical. Think of files as "name spaces", statistics in the statistics
files, partitions in the partition files

What is the downside ?

Think about the BSD Socket API - sendfile() wasn't hacked into send() either. It could
have been - anything could have been hacked into send, but it was saner not to.

: : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob Østergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:25    [W:0.089 / U:29.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site