On Sun, 9 Apr 2000, Bill Wendling wrote:
> It may be wordy, but it is standard, parsers do exist for it, and you
> don't have the fun of having 10 kagillion different file formats to
> parse.
>
> Sometimes the bleeding edge is a good thing.
There is no need to store it in XML, really, if data in /proc is
presented in a standard way. It would be easy enough to convert that
standard format to XML with a utility. Imagine:
procdump --xml /proc/net/*
procdump --text /proc/net/*
procdump --html /proc/net/*
My mythical procdump util here would be able to convert it very easily.
I am actualy growing fonder of the method of using the filesystem
completely and having no more than one value per file where the filename
is the attribute and the data is the value.
/proc/net/dev/interface
|
|--eth0
| |
| |--receive
| | |
| | |--bytes
| | |--packets
| | |--errors
| | |--drop
| | |-- ...
| | `--multicast
| `--transmit
| |
| |--bytes
| |--packets
| |--errors
| |--drop
| `--...
`--eth1
|
and so on.
hmm, I just noticed in the course of that that there is a counter for
recieve multicast but not one for transmit. Most likely to convert to XML
one might consider a directory as a tag ... maybe something like:
<proc>
<net>
<dev>
<interface>
<eth0>
<receive>
bytes=21421
packets=243
...
</receive>
<transmit>
bytes=27379
packets=246
...
</transmit>
</eth0>
If that is valid XML ... heck I am not real familiar with it.
Maybe sysfs as someone else mentioned might be better. Keep proc for
processes.
-
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/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:12 EST