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

[Dunlap, Randy]

> From: Ed Carp [mailto:[e-mail]]
> 
> Marcus Meissner ([e-mail]) 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