Subject: Re: sysinfo(2)
To: Simon Burge <simonb@NetBSD.ORG>
From: Aidan Cully <firstname.lastname@example.org>
Date: 04/08/2000 14:48:53
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
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.