Re: PROPOSAL: /proc standards (was dot-proc interface [was: /proc

[bill davidsen]

In article <[e-mail]>
	[e-mail] wrote:

| People should not shit a brick at the suggestion of doing _some_ things
| as binary structures.  The parts of /proc that really are intended for humans
| (ie. driver "debug" information... /proc/slabinfo, /proc/drivers/rd/..., etc.)
| don't make sense in binary.  However, there are loads of things that DO make
| sense in binary format -- too many things reference them for further processing
| requiring conversion from/to text multiple times.  The number of people
| who do:
|  % grep -l foo /proc/[0-9]*/cmdline
| instead of:
|  % ps auxwww | grep foo
| are very VERY low.

  There's a great savings, to convert what is initially a text string to
some "binary" format.

  The advantage of text format is that humans can read it, and if it
changes they can almost always figure out what it means. Not everyone is
a C/PERL hacker who is happy writing machine independent binary
structures, while virtually every language ever written can and will
parse those text strings, and when it won't you can see why not.

  Having spent a lot of time developing tools to use the contents of
/proc, I have to feel that the savings in time of not reinventing every
existing wheel is so far in excess of any possible saving that
justifying the change on effeciency grounds is at best unconvincing.

  There are so many new and useful things which could be done that I
can't imaging this make-work change to something currently in place to
be a useful investment of time.

-- 
bill davidsen <[e-mail]>
  His first management concern is not solving the problem, but covering
his ass. If he lived in the middle ages he'd wear his codpiece backward.