jakob@unthought.net (Jakob ¥stergaard) wrote on 04.11.01 in <20011104163354.C14001@unthought.net>:
> Here's my stab at the problems - please comment,
>
> We want to avoid these problems:
> 1) It is hard to parse (some) /proc files from userspace
> 2) As /proc files change, parsers must be changed in userspace
>
> Still, we want to keep on offering
> 3) Human readable /proc files with some amount of pretty-printing
> 4) A /proc fs that can be changed as the kernel needs those changes
And here's my proposal:
Backwards compatibility can be solved by keeping procfs as-is and creating
a new kernfs. (Ok, so this could also be done as a sub-tree of proc, or
any number of other ways ...)
The rest can be solved by defining a few generic file formats, and
insisting (via the interfaces exposed to kernel code) that only those file
formats will be used.
User space can further be helped by putting a format tag into the file
name, if that is necessary - a single letter should be enough here.
As general design principles:
1. Most files should be plain text.
2. Text values should use the most obvious formatting. (Such as using
10.1.2.3 for IP addresses, or 123.4 or 0.000234 for times in seconds.) If
units are needed and SI has a base unit for that area, use it.
3. Any files that can be written to for control reasons, should have a
single value and should read and write the same value. Unless it's a
commando-type of interface, but those should be kept rare (and should
probably read back some sort of status message). On read, there should be
no white space or line ends around the value.
4. Only use binary if the subject matter doesn't make sense as text. I
don't know that we actually have need for this - we certainly don't need
another /proc/kcore, and firmware download drivers don't belong here.
5. I think I can see a use for two different table formats.
One has every line be a tag, a colon, optional white space around the
colon and the tag, and a value; tags are unique, value formatting as in 2.
UP /proc/cpuinfo, for example. Values can have embedded white space if
that is necessary.
The other has a header line of white-space-separated tags, followed by
lines of white-space-separated values, one per tag. No value should
contain white space. /proc/net/rt_cache, for example.
6. There's a provision of having a list of similar directories indexed by
either a number or a name, for per-blockdevice, per-channel, per-network-
interface and so on.
Now, obviously, there'll be something I've missed ... but I think these
are fairly sane design principles, and if we insist on everyone keeping to
the defined formats and consider everything elkse a bug to be fixed, the
result is easy to parse, easy to change without breaking sane parsers, and
still human readable.
And we have made do with exactly three file formats, and could easily
write a very small generic parser for these formats.
MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Nov 07 2001 - 21:00:27 EST