But I think this is still innately record/field type data, and some
sort of schema that user-space tools can look up is a natural fit.
I agree that it should be human readable, and maybe a shadow directory
that's all binary would be an enhancement. The binary directory would have
the real data, and the /proc files that are human readable (i.e. all
characters) could be parsed and formatted from the binary directory on
demand, using the aforementioned schema. This is only a classic filesystem
from the user interface. Since it's all in memory anyway, why would the
kernel have to keep it all formatted all of the time?
Say you have
/proc/binary
/proc/syscfg
/proc/what_we_have_now
The only one modifiable from user-space is /proc/syscfg. /proc/binary
has the binary data and the schema files. When you want to read
/proc/meminfo with less, a /proc callback looks up meminfo in
/proc/binary, looks up the (cached at bootup) schema for that file,
and returns the formatted character data.
So the only time that a human readable /proc/file outside of /proc/binary
needs to occupy more than it's directory entry plus it's line(s) in the
schema cache in memory is when something is actually reading it's content.
There are four different goals here:
* intelligible content when you just read it directly with a shell pager
* good performance for tools that only need values in their binary form
* an organized representation that can easily keep /proc implementers and
/proc-using implementers on the same page
* accomodating labels in multi-byte locales (digits are
byte-per-character regardless of locale)
The last goal doesn't necessarily mean that you don't have fixed length
fields, just that the hard-coded length of labels changes in different
locales if someone sets their kernel up to use different /proc labels
than those used in the default /proc implementation.
Tagging clutters up the first goal, while facilitating the third goal and
adding backward-compatible extendability if done well, not impacting the
second goal much one way or the other. So the question is how to put the
parseability and extendability of a tagged records/fields implementation
in the schema, where we don't have to look at it when doing "cat
/proc/meminfo", but updating it just requires distributing the new
schema to tools developers. Schema files can carry version numbers.
Regards, Clayton Weaver <mailto:cgweav@eskimo.com> (Seattle)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/