Re: proposal for generic interface to /proc text files

Frank Wales (
Mon, 30 Sep 1996 15:30:09 +0000 (BST)

Keith Owens:
>On Sun, 29 Sep 1996, Rob Riggs wrote:
>> On 29-Sep-96 Daniel Quinlan wrote:
>> >This is a proposal for a generic interface for text files in /proc.
>> >It is designed to be easy to parse with most languages as well as
>> >humans. It is also designed to be extensible, modular, etc.
>> [various formatting suggestions omitted]
>> The only problem you seem to be addressing here is to make the /proc
>> entries a little easier to parse by a machine, with the formatting
>> information imbedded in the fields and records. This only makes
>> it more confusing to read by humans. Any program that uses specific
>> /proc files should already know how to parse them.
>One problem that has reared its ugly head is reading newer format proc
>entries with older programs. The current plain text /proc files are not
>suited to easy upgrades. It is difficult enough to add a field at the end of
>an existing line, often user mode utilities will break. Adding a field to
>the middle is just not possible without some form of tagged text. I know the
>standard response is "well if you upgrade the kernel you just have to upgrade
>your utilities as well" but how many problems have we seen because this just
>does not happen?

I think this is a key feature; I really like interfaces to mildly
structured data in the form of name:value pairs, because it does make
it easier to identify what you want without having to impose additional
structure on the information itself, structure that has to be known
by all participants. As Keith implies, having data explicitly tagged
makes the interface less fragile; how many people have been inconvenienced
because their version of ps or top of fuser breaks unexpectedly every now
and then? Related versions of this problem have already been solved (albeit
in a somewhat ugly fashion) by SNMP MIBs. Note that I'm less concerned
about making the /proc output more human-readable than with making the
interface between programs less fragile, but it would be nice if both
could be done. Most people likely to be looking at the contents of
proc files should have a reasonable idea what they're looking for anyway,
but it seems obvious to me that a list of tagged values is more
understandable than a row of anonymous numbers (although there are
many FORTRAN programmers who seem to believe otherwise...).

>I would like to see a clean break to tagged text for *all* proc files. That
>way we only get caught once when the change is made, thereafter user mode
>utilities will simply ignore /proc fields they do not recognise, making for a
>much cleaner upgrade path.

Of course, this is a clear benefit, but there is also a danger that
a semantic change will break the older utilities in a much more profound
way. It may also be worth considering the addition of a version number to
the proc data, which can provide hints to the programs that read the data
about whether it's legitimate for them to use it. For example,
the client programs must share the same major number, but can be out-of-date
on the minor numbers.

Frank Wales []
"Please state the nature of the Internet emergency."
               --the emergency holographic systems administrator