Messages in this thread | | | From | Frank Wales <> | Subject | Re: proposal for generic interface to /proc text files | Date | 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 [frank@limitless.co.uk] "Please state the nature of the Internet emergency." --the emergency holographic systems administrator
| |