Re: Suggested dual human/binary interface for proc/devfs

From: Terje Kvernes (terjekv@ifi.uio.no)
Date: Sun Apr 09 2000 - 17:24:42 EST


George Bonser <grep@shorelink.com> writes:

> 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.

sure. but what does procdump look like?

personally I'd like to see procdump at least not produce html, it
should instead produce XML and one should have a nice XSL to go with
that. but I digress. (this should exist no matter how one chooses to
display the information to users of course ,)
 
> 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.

yup. I agree. the problem as others have mentioned is consistency.
we either get some magical locking (a "snapshot" if you like). that
doesn't seem all that nice.

IOW taking the filesystem thought all the way may not be what we want.
is going half the way with the filesystem then a good idea?

[ snip pretty ascii drawing ]
 
> 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.

seems pretty ok. depending on your DTD and closing of the rest of the
elements of course. ;)
 
> Maybe sysfs as someone else mentioned might be better. Keep proc for
> processes.

maybe. I enjoy /proc for both purposes, but it's a bit ugly. and it
won't get any prettier anytime soon. moving all the system info to one
place, and making /proc a clean process-tree seems alluring. and
besides, proc is short for process, isn't it? ;)

-- 
Terje - for the first time on the kernel list. *wee*

- 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:13 EST