Subject: Re: sysinfo(2)
To: Aidan Cully <>
From: None <>
List: tech-net
Date: 04/07/2000 23:40:04
To: Aidan Cully <>
Subject: Re: sysinfo(2) (was Re: pidentd)
In-Reply-To: <>

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.