> Would it not be simpler to implement a set of system calls to return
> process information? No matter how much you optimize /proc its still a
> big drain on resources. (example: Top takes 5% CPU on PPro200 with ~100
> processes running. HP/UX "top" consumes less than 2% for ~400 procs on a
> PA-7150 100Mhz).
>
> I'm very much in favor of the VMS "$GETJPI"-like interface. It
> accepts as an argument an array of field descriptors (one for every
> requested process attribute) and a pid/procname/wildcard argument
> that specifies the process to find.
>
> Is this type of interface being worked on or would anyone mind
> terribly if it was implemented? An even better question: would this
> have a chance of being accepted into the kernel? Linus?
Hmmm. That sounds perfectly fine. It's not "easier" (I already have the
patch written that puts it in /proc/stat :) but is probably a bit easier on
system resources, if only marginally so. I guess it comes down to which is
more likely to be accepted into the kernel. Either way, I think -something-
should be done to get a faster look at the process information, because top
and similar programs are a beast.
Phil
--------------------------------------------------------------------------
'The ultimate seal on any software product is not any sort of kite mark or
standards conformance certificate, it's that label that says, "Destruction
tested by Alan Cox.... Survived."' -- Clive Dolphin (3Com PDD)