I think everyone agrees that standardisation of /proc would be neat,
and so would a little more latitude with modifications to /proc
wrt. not breaking tools which rely on it.
A couple of people have suggested a field-based approach, such as
parameter: value. This satisfies the second criterion, but removes
the flexibility to do formatting to make it more readable.
How about something along the lines of the current behaviour (dump all
fields as formatted ascii) for processes which simply read() proc, but
allow specific queries by a write() to proc, followed by a read()
which returns the value of the parameter requested by write(), or an
error. Maybe allow multiple write()s followed by a single read().
To set a value, make the write of form "param=value" and ban `=' in
parameter names. There could be a standard parameter name ("index")
to return a list of all parameter names.
Inside the kernel, the proc interface could allow registration of a
table of parameter names (rather than a simple function as used
currently) with associated type (sprintf format) & address, or a
function which returns the string. This allows generic proc code to
do the work of serving the "index" query, and values too trivial to
derive to need a dedicated function.
This is trivial to extend to allow binary information rather than
strings to be passed for those worried about conversion overhead,
say with a "b_" prefixed to the param name.
This approach doesn't handle tables, but are there cases where these
should *not* be separate files in a subdir of the /proc system (from a
user's point of view)? Can these cases be handled reasonably? I'd
like a less flat /proc myself I guess.
This is a real mud map; but noone mentioned it before... could those
who know more about this please pick holes?
Thanks,
Paul.
-- To Get Help:(1) Linux FAQ - http://www.li.org/Resources/linux-faq __________ (2) Linux HOWTOs - http://www.ecsnet.com Linux Clue| (3) Search for previous similar questions - http://www.dejanews.com Archive | (4) Read 50 messages comp.os.linux.setup, then post your question