Re: nproc: So?

[Roger Luethi <rl@hellgate.ch>]

On Sun, 19 Sep 2004 08:29:57 -0400, Albert Cahalan wrote:
> > Do you mean "return cookies for all existing processes"? Or "return
> > cookies for all processes created since X" (if so, what's X?) ?
> 
> First, queue cookies for all existing processes.
> Then, as process data changes, queue cookies for
> processes that need to be examined again. Suppress
> queueing of cookies for processes that are already
> in the queue so things don't get too backed up.
> If memory usage exceeds some adjustable limit, then
> switch to supplying all processes until the backlog
> is gone.

How is the kernel to know which changes of process data require
re-examination? In all likelihood, any tool is only going to be
interested in certain changes, not in others.

> I realize that the implementation may prove difficult.

It seems reasonable (and useful) to notify tools if new processes get
created. It is certainly possible to have additional events (like field
changes) trigger notifications, but this would probably become rather
intrusive and expensive.

> > With nproc as-is you can send a request that matches your desired struct
> > and cast the result to a pointer to your struct.
> 
> Either that's marketing, or I missed something. :-)
> 
> Can I force specific data sizes? Can I force a string to
> be NUL-terminated or a NUL-padded fixed-length buffer?
> Can I request padding bytes to be skipped over?

No, your data types have to match what the kernel offers. What I was
referring to was your request for "info in groups that match what /proc
provides today". What you _can_ do with nproc is, say, ask it to return
a pointer to something like this:

struct statm_extended {
	__u32 pid;	/*
	__u32 namelen;	 * My simple cookie
	char name[16];	 */

	__u32 resident;	/*
	__u32 shared;	 *
	__u32 trs;	 * /proc/PID/statm content
	__u32 lrs;	 *
	__u32 drs;	 *
	__u32 dt;	 */
};

Roger