From: erh@realms.nimenees.com
To: Aidan Cully <aidan@kublai.com>
Cc: tech-net@netbsd.org, tech-kern@netbsd.org
Bcc: 
Subject: Re: sysinfo(2) (was Re: pidentd)
Reply-To: 
In-Reply-To: <20000407120517.A15367@xanadu.kublai.com>

On Fri, Apr 07, 2000 at 12:05:17PM -0400, Aidan Cully wrote:
> I've been thinking for a while about a 'sysinfo' syscall, which would
> behave quite a bit like using sysctl() to read values from the kernel,
> but with the addition of a 'flags/flaglen' argument pair for allowing
> the kernel to do a lot of the filtering on the data before it goes to
> userland...  I haven't done anything with it, because I couldn't think
> of any major advantages of it over using sysctl().  Maybe it would be
> well suited to this function, though?
	Well, it looks like sysinfo() changes void *newp from sysctl() to
something with a more defined structure instead of each sysctl for itself.
What kind of filtering would this enable you to do?

> I was thinking about it as a general replacement for anything that used
> libkvm against a live kernel.  Most of the motivation was in those
> periodic 'proc size mismatch'es that /bin/ps gives when upgrading the
> kernel, but done a bit differently sysctl() could avoid those as well.
	I thought this was from the struct proc changing when upgrading
the kernel?  Wouldn't the solution to this be to define struct kinfo_proc
not in terms of a struct proc but with a standardized proc-like structure?
Then perhaps also have a separate sysctl to get the full info.
	Another neat thing would be, when handed a NULL oldp, for the
KERN_PROC sysctl to allocate the space to build the array of kinfo_proc
itself and save it.  Then, when the next KERN_PROC call, with an oldp,
comes in it returns the saved info.  Another NULL oldp request from the
same process would replace the previous info and a timeout could handle
reclaiming the space if the process never retrieved it.

eric