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.)
-- Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu Some things are not improved when made "graphical". Imagine how crude Kilmer's "Trees" would be if reduced to comic-book form.
- 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/