Aidan Cully wrote:

> 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...

The idea I had in mind was not to put a struct proc inside struct
kinfo_proc at all, but have each individual field that we want copied
over.  Any changes to fields (say an int32_t to an int64_t) would
meaning keeping the current field as is and adding the new one to the
end of struct kinfo_proc.  This would obviously make the kinfo_proc
filler handler a bit ugly, but then it's just a matter of that handler
filling the current struct kinfo_proc and then doing the equivalent of

	memcpy(user-supplied-kinfo_proc, real-kinfo_proc, elemsize);

for each requested process.  This way the kernel doesn't need to
remember an endless number of versions.

> 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.

I'd be curious if anyone actually knows now the HP/UX pstat*() index
stuff is implemented (bcc'd to someone who may know).  The other option
is to forget about the index stuff altogether and do what we currently
do - call sysctl() with a null oldp and get the number of "things"
available in oldlenp.

Simon.