RE: proposal for generic interface to /proc text files

Dan Hollis (goemon@sasami.anime.net)
Mon, 30 Sep 1996 03:43:13 -0700 (PDT)

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