Messages in this thread |  | | Date | Mon, 30 Sep 1996 03:43:13 -0700 (PDT) | From | Dan Hollis <> | Subject | RE: proposal for generic interface to /proc text files |
| |
On Mon, 30 Sep 1996, Keith Owens wrote: > 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 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.
I agree. /proc should be standardized ASAP. That would prevent the problems with upgrading procutils when fields change in the future (and you can bet 100% they will.)
While I am at it may I suggest a couple additions to /proc:
We have a scsi/ directory, why not an ide/ as well.
Anyone want to start up a mailing list on this?
BTW it would be nice to get kernel messages cleaned up and standardized as well. For example, I don't need the Buslogic driver telling me the life story of every scsi device on the system on bootup. This can be considerably pared down. I don't mean something so terse as Free/NetBSD(I), but something a lot less verbose. As it is the Buslogic driver alone takes almost a screen of output on bootup.
-Dan
|  |