But at the moment, every /proc file is slightly different, and while they
are human readable, they are also rather fidgety. If you slightly change
the format of one of them, it can break any utility which uses it, if say,
the utility was expecting four numbers representing something to be on one
line, but now a new number has been added into the middle (examples: the
recent problems people have been having with the 2.1 kernels because
ifconfig started reporting wacky stuff after the format of some files it read
changed, or the segv's of ps-utils back in the 1.3.x days).
Instead, what has been proposed (and I think is a good idea), is change
every file so it is of a paired up format, with an identifier and a value
on each line. Programs written to take advantage of this would then look
for identifiers in /proc files to extract the information they need, and ignore
any identifiers they didn't understand, instead of breaking. Quick
example of what could be done:
/proc/meminfo changed so that only one piece of information is put
on each line, instead of the table like format it has now. A human would still
be able to read this if they needed to, or more likely they would use free
(whose maintainer would be a much happier person now that /proc/meminfo is
so much easier to parse) to display the information.
Duplication of the information wouldn't be necessary. And it might be
nice to actually have a good /proc standard nowadays (the proc(5) man page
is nice, but to my knowledge it hasn't been updated in a while...)
>I like the idea of /proc fs standardization (if this isn't already the
>case, I'm not knowledgable in this area). However, it is my opinion that
>"machine readable" (i.e. NON human readable) duplication of the
>information is unnecessary and would cause kernel bloat. I have talked
>with many WinXXXX developers who are of the opinion that NON-human
>readable stored data is for some reason exceedingly hard to
>access/read/etc. I too, perhaps, was of this opinion long ago. However,
>it simply isn't true. Yes, there is some _slight_ additional complexity
>involved with translating human readable data into appropriate data
>structures, but once you become comfortable with the algorithms to do so,
>the task becomes relatively trivial. And the payoff for storing such
>information in human readable form is *immense*. It aids debugging and
>system administration greatly and it's completely platform independant
>(endian, alignment, etc).
-- Andy Berkheimer | Home: andy@tho.org aberkhei@acm.org | Work: andrewb@mitre.org