> On Sun, 1 Nov 1998, David Holland wrote:
> > 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.
>
> Sounds like exactly what I'd like.
>
> [many benefits omitted]
> > 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.
>
> Nope. If sysctl() (or something like it) could be fed a *list* of desired
> data then you could nab it all (well, for an already-known list of
> processes) in two context-switches. The locking grossness remains,
> however.
>
> Essentially you have to turn the scheduler and much of the I/O system off
> until everything is returned, if you want *perfect* consistency. (You
> could have another syscall to do that, but then what happens if the
> requesting process croaks before re-enabling the scheduler? Ugh. I
> suppose that all returnable quantities could be journalled, and you could
> declare a snapshot and then retrieve at leisure only what was true then.
> Double ugh.)
>
It seems to me that you are reinventing the /dev/kstat interface that is
present in Solaris. Just do a man kstat on a solaris box...
If this was ported to Linux we could run Virtual Adrian on Linux. :-)
Hans Eric
-
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/