[lkml]   [1997]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Machine friendly format for /proc files
> 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.
The complaint here is that the output is either machine-illegible, or
needs a different routine for each file. It would be good to have some
sort of standardized format which would allow both machines and humans
to read /proc files easily.

> >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.


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