On Sat, Apr 08, 2000 at 11:52:38AM +1000, Simon Burge wrote:
> Aidan Cully wrote:
> > 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 was thinking about something similar to this just this week, having
> been exposed to HP/UX for the first time and having to get some info
> about a process from a user land program.  The pstat*() calls that take
> the (buffer, elem_len, num_elem [, index]) arguments seem to be a good
> way of fixing the 'proc size mismatch' problems we have.  From the man
> page:
> 
> 	"As the system changes, some fields may be added.  However,
> 	since any new fields will be appended to the structures, and the
> 	call to pstat() passes the expected structure size in elemsize,
> 	a program can continue to work without recompilation.  If the
> 	user program is recompiled, the additional pstat() fields will
> 	be available."

I think we can use the components of sysctl()'s 'name' parameter to
provide version information for filling out the process table.  Every
time struct proc changes size, KERN_PROC could change value, and get
mapped to compatibility routines for returning the old format
structures from the kernel.  It also allows for fields being removed
from struct kinfo_proc...

> It may be sane to make this a read-only interface, since it's made to
> cope with backwards compatible structure sizes.  Using sysinfo() as a
> name, the prototype could be something like:
> 
> 	int sysinfo(int *name, u_int namelen, void *indata, size_t elemsize,
> 	    size_t elemcount, int index);
> 
> where index has the HP/UX meaning of "give me `elemcount' items starting
> at item number `index'".
> 
> Thoughts?

elemcount/index, of course, allows for the possibility of the kernel
structures changing from underneath the caller's nose between
invocations of sysinfo()...  Now that I've started thinking about it,
maybe a sysinfo() type interface would want a helper sysinfo_lock()
function (taking the same name/namelen parameters), which would
atomically copy the table requested into a buffer, and future
sysinfo() invocations would operate on that buffer?  (same things erh
talked about WRT freeing the sysctl() buffer would apply here...)  It
would allow for an elemcount/index approach to reading kernel data.

--aidan