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}...............: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/