Re: ARMS WAVING!!! Proposal to fix /proc dainbrammage.

David Holland (dholland@cs.toronto.edu)
Sun, 1 Nov 1998 18:35:36 -0500


> I know that making sysctl() calls is better but my Linux bible (Linux
> Device Drivers) doesn't mention anything about it, and so I don't know if
> it's possible to make sysctl() calls to a module, unfortunately. If I
> could, then I'd use sysctl() instead of ioctl().

In the VINO kernel (http://www.eecs.harvard.edu/vino/vino, that is,
what I did on my summer vacation^W^W^H last job) there is a /kern
filesystem that's functionally equivalent to Linux's /proc.

However, it has the following characteristics:
- *all* of the data is available through both /kern and sysctl().
- each file in /kern is a single datum.
- sysctl() retrieves binary data, /kern retrieves ascii data.

The kernfs code provides common code for typing and ascii to binary
conversion and permissions and other useful features. The marginal
cost of another sysctl variable in VINO is nearly zero in code size -
you just have to create and initialize it - and not very much in data
size, essentially just a stripped-down inode structure. So having
hundreds of them (because of using directories to hold the field
names, essentially) doesn't cost much.

Furthermore, /kern is still quite accessible to humans (arguably, more
so than Linux's /proc, because all the fields are labeled.)

It's more accessible to scripts than Linux's /proc, because you can
always find the fields you want and you don't have to write any
parsing routines at all: field lookup, as it were, is done with
open().

Binaries, such as ps or netstat, can use sysctl() for heightened
efficiency. There's a direct 1-1 mapping between sysctls and paths in
/kern, so it's easy to figure out what sysctls to use. And all of the
sysctls return ints or strings; no structs that then become part of
the kernel API.

The only drawback is that for something like ps you have to open a lot
of files or do a lot of sysctls, so it's not lightning-fast, nor do
you get ideal consistency/atomicity properties.

But, the only way to get perfectly consistent output from ps is to
have a single entry point of some kind that returns *all* the process
data for the entire system all at once, locking everything as
necessary. And that's pretty gross.

-- 
   - David A. Holland             | (please continue to send non-list mail to
     dholland@cs.utoronto.ca      | dholland@hcs.harvard.edu. yes, I moved.)

Any netkit mail should be sent to netbug@ftp.uk.linux.org, not me.

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