"Monitoring" a process

In an article, mtxinu.COM!shore (Melinda Shore) writes:
> In article <382 at bria> bria!mike (Michael Stefanik) writes:
> >IMHO, there should be a function called procstat() that returns a pointer to
> >an array of 'proc' structs.  Of course, it'll never happen.
> 
> That's not very general.  There are many kernel data structures that
> are interesting/useful/whatever, and you shouldn't need a different
> system call for each one.  Instead, you can use something like the
> table system call (which Mach HAS) or the tabinfo/tabread system calls
> (which Unicos HAS). [...]

This is part of the problem; here are two marginal (read: not dominating
the commercial marketplace) flavors that are doing things their own way;
this is just as bad having to read the namelist, in terms of portability.
There needs to be a general, consistent way for the "average joe" programmer
to get process information without having to dig through the bowels
of the kernel.  A general system call that would copy kernel structures into
a user's address space would be nice, but, then again, you run into some
implementation specifics.  Relatively speaking, I want a printf() and you're
saying, hey, no problem, there's this function called write().  Just
like the "average joe" doesn't worry about how printf() is actually writing
to his terminal, he shouldn't have to worry about the kernel specifics
of processes.  This is one case where I think that a "black box" approach 
would be generally welcomed. (And since I enjoy taking laziness to new, 
previously unattained heights, I wouldn't mind either ... :-)

> Also, from within the kernel you don't have to
> read the namelist, because, of course, addresses are known at link
> time.  And names of kernel data structures don't vary that much within
> major Unix strains (or even among them - is there a Unix out there where
> the name of the proc table isn't "proc"?).  You'll find sysinfo in just
> about any sysV variant there is, for example.

I was playing fast-and-loose with some terminology here.  In re-reading
what I wrote, it was nonsense.  1) of course the kernel knows the
address of it's own process table, and 2) there ain't no way that a
user process is going to get handed a pointer to structures the reside in
kernel memory.

How about the process table as a shared memory entity that can be
attached to by interested processes?

> [BTW, I would have sent you email about this but your "Reply-to:"
> line totally loses and you have no From: line in your header.]

Yup.  My news is brain-damaged.
-- 
Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation
UUCP: ...!uunet!bria!mike
--
technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly
found to be saying things like "Well, it works on my DOS machine ..."