public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Jakob Østergaard" <jakob@unthought.net>
To: Mark Hahn <hahn@physics.mcmaster.ca>
Cc: linux-kernel@vger.kernel.org
Subject: Re: IO stats in /proc/partitions
Date: Mon, 6 May 2002 16:04:43 +0200	[thread overview]
Message-ID: <20020506160443.P26111@unthought.net> (raw)
In-Reply-To: <HBEHIIBBKKNOBLMPKCBBCEAOEMAA.znmeb@aracnet.com> <Pine.LNX.4.33.0205041718290.4175-100000@coffee.psychology.mcmaster.ca>

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.

-- 
................................................................
:   jakob@unthought.net   : 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.           :
:.........................:............{Konkhra}...............:

  parent reply	other threads:[~2002-05-06 14:04 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-04 19:59 IO stats in /proc/partitions Andries.Brouwer
2002-05-04 20:35 ` M. Edward Borasky
2002-05-04 21:25   ` Mark Hahn
2002-05-05  1:04     ` M. Edward (Ed) Borasky
2002-05-06 14:04     ` Jakob Østergaard [this message]
2002-05-04 21:35   ` Tomas Szepe
2002-05-05  1:08     ` M. Edward (Ed) Borasky
2002-05-05  1:18       ` Mike Fedyk
2002-05-05 16:55     ` Denis Vlasenko
2002-05-05 18:10       ` M. Edward (Ed) Borasky
2002-05-05 23:51         ` Thomas Zimmerman
2002-05-04 22:53 ` Alan Cox
2002-05-04 22:46   ` H. Peter Anvin
2002-05-15 21:39 ` Marcelo Tosatti
2002-05-15 23:18   ` Miquel van Smoorenburg
2002-05-16  0:30     ` Alan Cox
2002-05-20 18:19       ` Bill Davidsen
2002-05-21  0:36         ` Guest section DW
2002-05-21 13:11           ` Alan Cox
2002-05-16  7:50   ` Christoph Hellwig
2002-05-23 20:27     ` Marcelo Tosatti
2002-05-24  9:56       ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2002-05-05  1:38 Nivedita Singhvi
2002-03-12 15:34 Jean-Eric Cuendet
2002-03-12 21:51 ` H. Peter Anvin
2002-03-12 22:48 ` Anton Altaparmakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020506160443.P26111@unthought.net \
    --to=jakob@unthought.net \
    --cc=hahn@physics.mcmaster.ca \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox