Re: proposal for generic interface to /proc text files

Albert Cahalan (
Sun, 29 Sep 1996 15:23:03 -0400 (EDT)

> 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.
> This issue of particular interest of me since it is related to the
> filesystem interface of Linux and also because I'm to blame for the
> proc(5) manual page (where I became disgusted with the inconsistency
> in the /proc interface).
> This could be implemented in the 2.1 experimental series. A patch to
> update /proc to use this proposal would be very easy. Most files
> would only require minimal modification. Cleaning this up now, while
> some files in /proc are not actually used by programs would be better
> than waiting until later when more files are in use.
> Records
> Text files in /proc are composed of "records". The end of a record
> is indicated by a newline. Most files will have only one record,
> but some may have multiple records, such as cpuinfo on SMP
> machines and the device list in /proc/pci. The terminal newline is
> omitted from the last record in any file.
> Fields
> Records are composed of "fields", which are delimited by a newline.
> Mulitiple line fields may be continued past a single line by
> preceding each additional line with a tab. (The last field in a
> record is followed by a newline. If there is another record in
> the file, there is another newline, creating a blank line to
> separate different records.)
> Subfields
> Each field is composed of "subfields". Subfields are delimited by
> a single space. Subfields should not be justified or padded with any
> extra whitespace. These characters should probably be prohibited
> from records: tab, backslash, and space, single quote, double
> quote, and apostrophe. I'd like to recommend lowercase letters
> (in the Unix tradition), but don't feel it would be smart to
> prohibit uppercase letters.

We can't put filenames in /proc then, unless we also prohibit all
those characters in ext2 and NFS - oh, NFS is not our standard...

That is also to slow for some things. I suggest that _most_ files
in /proc should be padded to 2^n bytes. For example, 31 characters
plus a newline or 127 characters plus a null. Then the block size
will be an exact multiple of the line size, so the code is simple
and fast.

> Numeric subfields
> We need to decide on a common format for different types of numeric
> fields (common for instances of a type, not for all types). Memory
> addresses should all be in hex format (0x0123), ranges should be
> expressed as [number]-[number], IP numbers should be in a
> consistent format (not necessarily hex), etc.

If the network tools can take hex, then that would be best. Hex is
great for looking at netmasks and such. Hex is also fast to read/write
with a custom function. Otherwise, I'd hate to use decimal in all the
tools but see hex in /proc.

> Labels
> The first subfield in any field is a "label" if there are multiple
> fields in the record. Labels are followed by a colon character,
> which is not separated from the text of the label by any whitespace.
> Comments
> Including comments or extra unnecessary information in text /proc
> files are discouraged. Please update the proc(5) manual page as
> necessary.

True, but a small /proc/README could be an exception.