Why? If the individual /proc pages remain consistent and don't
change, it is easy enough to parse them. The inconsistency
across the various /proc files is an aesthetic issue, not a
programming issue.
>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).
I would agree that the _visual_ inconsistency of the various /proc
pages is aestheticly displeasing. But one must realize that a
standard can only be suggested, not imposed.
>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.
[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.
There are other means to get the text information into a data
structure. Possiblities include:
a) Hidden /proc entries that output binary data, which
correspond with the text entries. (e.g. /proc/.meminfo
corresponding to /proc/meminfo would just copy a struct
sysinfo into the buffer.) [hackish; lots of coding]
b) libproc. [Very bad idea. Sorry I mentioned it.]
c) An ioctl interface to the the various /proc subsystems.
Note: each /proc subsystem already maintain seperate
"struct file_operations" that can include a pointer
to an ioctl routine. [like "a" above, it would require
lots of coding; suboptimal]
d) A <linux/proc.h> that somehow describes the formatting
for the various /proc interfaces. [unobtrusive, but
difficult at best]
I honestly don't think any of these are needed. And imbedding
formatting information in the entries themselves is an even uglier
solution to the (non-existant, IMHO) problem.
I think a Proc_Style document would be welcome. However, one
cannot expect all developers to follow its suggestions.
Rob
(rriggs@tesser.com)