> From: Ed Carp [mailto:erc@pobox.com]
>
> Marcus Meissner (Marcus.Meissner@caldera.de) writes:
>
> > The longer I follow that syntax thread the more I like the
> VFS approach with
> >
> > /proc/.../net/devices/eth0
> > transmit/
> > bytes
> > packets
> > errors
> > ...
> > receive/
> > ...
> >
> > Advantages:
> > - Easy to parse and use for scripts.
> > - Easy to read for humans.
> > - Unproblematic
> > - Easily extendable, will not break scripts when extending.
> >
> > Disadvantage:
> > - When reading bytes/packets you might get slightly different
> > views for new packets may have arrived.
>
> The other disadvantage, if I understand your implementation,
> is that multiple files need to be opened and closed. Why not
> just have /proc/net/devices/eth0 and have all taht stuff in
> one file? Then you just have to open and close one file,
> instead of a dozen.
Continuing evaluation of these possibilities,
the VFS method uses a file name as an attribute name,
with only a single value in each file.
The alternative of multiple values in /proc/net/devices/eth0,
for example, would have lines of the format "name=value"
(maybe).
So a program (or script) can know the VFS directory structure
and just open eth0/receive/packets, eth0/receive/bytes,
eth0/receive/errors, etc., but it would be better (smarter)
if this program (or script) read eth0/receive to see what
files (attributes) are there and then tried to do something
with them intelligently, so there is overhead not only of
reading N files for N values, but also of reading the
directory entries at each level.
If there was a really good answer to this, I'm sure it
would already be in the kernel.
~Randy
-
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:16 EST