Re: Machine friendly format for /proc files

Mark H. Wood (mwood@mhw.OIT.IUPUI.EDU)
Wed, 19 Feb 1997 13:10:24 -0500 (EST)


On Mon, 17 Feb 1997, Floody wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
>
> On Mon, 17 Feb 1997, Elwyn B Davies wrote:
>
> [ Snip ]
>
> > Unfortunately the format of the various /proc files is pretty much ad hoc and
> > primarily intended to be human readable rather than machine readable. It is
> > also essentially unsupported - it is not a specifically documented and
> > maintained interface - so in some ways it is just as bad as fishing around in
> > the kernel directly. The agent has to be aware of the format of each file and
> > provide specific decoding for the format provided by the device driver writer.
> > Accordingly, a minor change to the format can break the agent.
> >
> > We propose that it would be very convenient if a more machine friendly and
> > standardised format was added to the /proc files. Something like the
> > M****soft Windows initialisation file format is what we would be looking for
> > (surely they didn't get something right ;-) with parameter/value pairs divided
> > into sections plus comment facilities.
>
> I like the idea of /proc fs standardization (if this isn't already the
> case, I'm not knowledgable in this area). However, it is my opinion that
> "machine readable" (i.e. NON human readable) duplication of the
> information is unnecessary and would cause kernel bloat. I have talked
> with many WinXXXX developers who are of the opinion that NON-human
> readable stored data is for some reason exceedingly hard to
> access/read/etc. I too, perhaps, was of this opinion long ago. However,
> it simply isn't true. Yes, there is some _slight_ additional complexity
> involved with translating human readable data into appropriate data
> structures, but once you become comfortable with the algorithms to do so,
> the task becomes relatively trivial. And the payoff for storing such
> information in human readable form is *immense*. It aids debugging and
> system administration greatly and it's completely platform independant
> (endian, alignment, etc).

Well, there is human-readable and then there is human-readable. The
stuff in /proc might just as well be "tag: value" as

struct foo
{
unsigned char tag;
int value;
};

but OTOH there is no need for headers, fancy formatting, etc. The raw
/proc output can be decorated or reformatted using simple scripts.

The problem is that if the output is supposed to be human-readable, there
is a tendency for all this unnecessary formatting junk to creep into the
/proc code despite all our best intentions. I guess we'll just have to
resolve to be more disciplined in future.

Mark H. Wood, Lead System Programmer MWOOD@INDYVAX.IUPUI.EDU
Those who will not learn from history are doomed to reimplement it.