From: erh@realms.nimenees.com
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
Cc: tech-kern@netbsd.org
Bcc: 
Subject: Re: new sysctl(KERN_PROC, ...) interface (was: sysinfo(2))
Reply-To: 
In-Reply-To: <200004160211.WAA02071@Twig.Rodents.Montreal.QC.CA>

On Sat, Apr 15, 2000 at 10:11:56PM -0400, der Mouse wrote:
> The biggest problem with this, it seems to me, is, where do you store
> the snapshot?  It has to be somehow associated with the calling
> process, or you can easily have two processes racing against one
> another.  But even if you hang it off the process (somehow), you still
> have reentrancy problems - the strtok() problem, to put it loosely.
	have the KINFO_PROC2 code keep a table of requests? Store a
handle and a process number in the table?  Limit the number of entries
a process can have to 1.

> Unless you can somehow invent a handle that the snapshot call can pass
> back to the process, which would then be handed back to the
> read-snapshot call...at which point it seems to me you might as well
> call that handle a file descriptor and go with kernfs and/or procfs,
> since sysctl is already hopeless on kernel corpses.
	Ok sure.  But then you have to make sure kernfs and/or procfs
is mounted.  That sucks.  You shouldn't need that.

	Hey.  I think I just convinced myself that this should use a 
special type of socket.  (argh, I wish I could remember who suggested
that, or what list it was on.)  make socket with domain of KINFO, protocol
PROC_INFO, write the size of your struct kinfo_proc2, read the total
size, then read the kinfo_proc2 table.  When you're done, close or
write the size again, repeat.

eric