On Sun, 9 Apr 2000, Anthony Barbachan wrote:
> > Disagree. Too many bytes to describe something that should be really
> simple, and you have to write your own parser, etc. Please don't try to use
> the latest technological whizz-bang as a solution for a problem that doesn't
> exist.
> >
>
> I would suggest the .ini file type file format, like what Samba uses. Its
> relatively easy to parse and also quite understandable to most people.
ANY kind of common format would be fine. Just looking at the differences
between /proc/cpuinfo and /proc/devices shows how difficult it could be to
have one single parser for all /proc files. Something like this world
work.
/proc/cpuinfo
processor 0 {
vendor_id:GenuineIntel
cpu family:6
model:6
...
}
processor 1 {
same stuff
}
Things are grouped with braces, leading white space ignored till first
char. After first non-whitespace char everything is significant up to
attribute:value deliminator ":" in this case. Note even the inconsistancy
inside cpuinfo ... vendor_id vs. "cpu family" instead of cpu_family.
Things are not even consistant within the same files.
If the data were presented by the kernel is a format such as the above, it
would be a simple matter to build a generic user space parser with final
output in XML or human readable form or whatever. Simply tell the standard
parser what you format you want. The basic problem is that there is no
consistancy to the stuff in /proc.
Heck, you could even collapse some existing subdirs into a single file ...
/proc/sys/net/ipv4/... might be an example. Seems we are using the
filesystem as a sort of pre-parser.
Have a look at /proc/net/dev for a completely different format. It's gotta
suck but I imagine a lot of programs rely on these weird formats.
then again ..." Backwards compatability is not a priority with us Yanks"
gb
-
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