> "Next I compiled the original version which worked but spawning off a
> ps every .75 secs to collect CPU usage tended to adversely affect the
> CPU usage of my friend's 386SX/16 :-)
IMuneducatedO, spawning off a ps every .75 seconds is going to cost you
a lot more than just reading the /proc file. Consider that you have to
open the file /bin/ps, just as you would the /proc/whatever, and disk
should generally be way slower than virtual as well.
Thinking about it, say you have a script that needs to know CPU usage on
a regular basis. The old way would be to run ps, push it through grep,
awk or some such tool, with /proc you can use grep or awk directly on
the /proc file (unless I miss something here - I've never actually
*done* this)
Now isn't that a lot simpler?
> This was a bad thing. The code was an ugly hack but I don't hold that
> against it. The idea is great."
[...]
> Now, wouldn't a kernel module be totally kind to the system...
How do I access a kernel module from a shell script -- I'm going to have
to use some C program, like "ps" in the old version above, that's how.
In many cases, we're back were we started. And while we're at it, how
do I check for its presence and provide a workaround for systems where
this module doesn't exist?
> and remember, two page optional modules aren't bloat in my opinion...
Yes it is, when the feature it provides just serves to duplicate an
already existing (and superior) feature already in the kernel.
If you really think this is important, you should take the 2.0 sources,
add the syscall you want, and demonstrate that things are significantly
faster in at least some cases.
> The Microsoft NT 4.0 build 1314 (beta 2 CD) kernel is about 4MB in
> memory. THAT is bloat! :-)
NT? What's that? Certainly not something we want to use as a measure
for code bloat. QNX, on the other hand...or Minix.
~kzm