The one value per file is real nice for when you know exactly what value
you want.
/proe/net/eth0/bytesreceived has your value, so just read it.
The .dump file is there for things like ps which need to pull in a whole
bunch of data in one gulp. Of course ps could just open each and every
file (no parsing that way), but I would be afraid of too much overhead.
So, once you like the .dump idea, the problem is coming up with a format
that people like. But wasn't that established in the first part of the
problem?
Why can't /proc be populated by a heirarchy of single value files, and
each directory has a .dump (or whatever) file which has a text
representation of the directory structure?
# ls /proc/net/eth0
bytesreceived
bytestransmitted
blah1
blah2
# cat /proc/net/eth0/.dump
bytesreceived/1234
bytestransmitted/23345
blah1/23
blah2/3
# cat /proc/net/.dump
eth0/bytesreceived/1234
eth0/bytestransmitted/23345
eth0/blah1/23
eth0/blah2/3
eth1/bytesreceived/52323
eth1/bytestransmitted/23412
eth1/blah1/123
eth1/blah2/12
So no you can either:
RECEIVED=`cat /proc/net/eth0/bytesreceived`
or
RECEIVED=`cat /proc/net/.dump | grep bytesreceived | cut -d / -f 3`
(repeat the 2nd one above if you want to populate an array of such values
with just a single "read" from proc)
I think someone said this would be bloat, but I'm not sure where. The
information is already stored in the kernel (it's gotta know what value
exists in which directory), and the scripts would just use whatever values
it wants.
Of course a 'cat /proc/.dump' is going to be real long, but isn't that
what you asked for? You still get one value per line (in .dump) which
makes the shell people happy. You still get the nesting which the
dhcp-configstyle people happy.
-kf
On Wed, 12 Apr 2000, Olaf Titz wrote:
> > And so it becomes much easier to parse, and much easier to visually
> > understand, instead of a bunch of stuff indented with braces running
> > down a page. Even easier would be:
> >
> > eth0 192.168.201.116 255.255.255.0
> > eth1 192.168.201.117 255.255.255.0
>
> _No_. This is how /proc/PID/stat, /proc/net/dev and others currently
> look like, and it means that user level code will have to be adapted
> whenever an item is added to the format. That is bad bad bad.
>
> We need a tagged format, where each item is unambiguously labeled. Yes
> this makes it a bit more verbose, but parsing it is just as trivial.
>
> With this format
>
> device=eth0;ip_address=192.168.201.116;netmask=255.255.255.0;
>
> (note the trailing semicolon!) you can say "give me the netmask of
> eth0" as
>
> fgrep "device=eth0;" /proc/... | sed -n 's,.*;netmask=\(.*\);.*,\1,p'
>
> in a simple, natural (to Un*xheads) way and this won't break if
> sometimes the /proc entry suddenly becomes
>
> device=eth0;mac_address=00:40:33:B0:1C:9F;ip_address=192.168.201.116;netmask=255.255.255.0;
>
> in the next kernel version.
>
> Olaf
-
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:19 EST