proc table in /dev/kmem

[Barry Shein]

From: jmd at loral.UUCP (John McDaid)
>Hello,
>
>I have a situation where given a process id, I need to find the child(ren)
>of that pid.  The only way I can think of doing this, without execing
>some kind of shell script that runs ps -l through awk, is to get the 
>necessary information out of the process table via /dev/kmem.

Why are you so shy about groveling a ps listing? You don't have to use
awk if you're worried about all the overhead/memory, you can use
popen() and just get it yourself with a little string manipulation.

Think of it this way, given that you'll mostly have to duplicate all
of ps's code (it's probably doing it correctly) into yours, and that
ps (or your code) will spend most of its time doing I/O on /dev/kmem
anyhow the fork/exec of ps is a tiny cost (I could go along with
fork/execing things like awk therafter is unacceptable to you, but I
doubt you'll get what you want much faster than just forking ps.)

If ps seems slow on your system it's probably not the fork overhead,
you won't likely do better, there's no such thing as a free brunch.

And note that /dev/kmem on many systems is becoming only readable to
setgid programs (eg. ps) so if you don't use ps your program may stop
working somewhere else, or someday and need a complete rewrite anyhow.
And if your code is just a clone of ps you won't be able to give it
away.

Unless there's some very special reason you don't want to fork ps that
you're not telling us I say do it, and get onto unsolved problems.

I can't tell you how many times I've just popen'd a ps (or even an ls
for that matter, particularly in the days when directory reading was
less portable) and I've never been sorry. And I'm very impatient.

Do it like the pros, cheat!

	-Barry Shein, ||Encore||