> >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.
As seen with ifconfig on recent kernels. I was about to propose that,
at least for column-formatted stuff like /proc/net/dev, the first line
be parseable...but then I saw 2.1.26's two-line (bleah) over-80-column
(bleah part two) format, with the extra line's content not even aligned
(bleah part three) with the major line... Matter of fact, the "bytes"
and "carrier" entries are also misaligned (left and center, resp.) compared
to the other headline entries (right)...
> > 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.
That sounds fairly good; I'm not sure whether we want 2D tables like
/proc/net/dev to stay line-per-device, or be line-per-parameter; their
2D format does mean you'll have to keep track of both rows and columns
anyway, and doesn't succumb to any compact 1D format...
> 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 concur. We're not trying to define a binary format, simply an easily
digestable format suitable for both humans and machines, which wouldn't
vary much from /proc file to /proc file.
Keith