Nope. /proc would use a standardized format. Point. The type of entries in
/proc files is not every extending. Not more than the list of C types is
expanding every week:
Basically, one could simply use something like BerkeleyDB (I know, it's
overkill, but it's just for the sake of concreteness) where every label ("left
hand side", or "entry" if you prefer) would be a 4-bytes or 8-bytes (as you
wish) value (that could be interpreted as a string, like Mac file-types are
4-bytes interpreted as 4-char names) with the last char (à la Basic) would
indicate the type of the corresponding value (right-hand-side).
The type could be string, int, real, boolean or another DB.
(basically, DBfiles would here be looked at as dynamically-types structures).
Of course, instead of DB files, I'd use something more like sequential list of
entries, but who cares. Incidentally has anyone thought seriously about making
part of the kernel address-space accessible from userland ? I'm thinking about
it now because I already have libz in my kernel (for e2compr), so if we keep
adding stuff there (like libdb), it would be neat to be able to reuse that
instead of having duplicate copies (it would mitigate the cost of putting such
stuff in the kernel).
Stefan
> Having the kernel produce text doesn't cost much, and is IMHO well worth
> it. If you want a binary interface, system calls are there.
Text is badly unstructured. If the kernel could decide on a standard scheme of
structured types, they could be supported everywhere and wouldn't be more of a
hassle to use than is text right now. Lisp machines are a (still living) proof
of concept.
Stefan