On Sat, Apr 08, 2000 at 11:11:57PM +1000, Simon Burge wrote:
> 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.

We're in violent agreement, here...  I wasn't thinking too clearly
when I wrote 'struct proc' there.  Was around 2:20 AM, locally.

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

Well, obviously struct kinfo_proc won't need to change size nearly as
much as struct proc does, but I see your point.

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

Without some kind of locking, or buffering, it's always going to be
possible for the tables to change from underneath you when you use a
series of syscalls to talk to the kernel...  Using this approach, the
size of the table can change, but nothing else.

later,
--aidan