Re: proplib and the jet age

[David Holland <dholland-tech%netbsd.org@localhost>]

On Fri, Jan 04, 2013 at 08:50:35PM -0600, David Young wrote:
 > > It seems to me that the basic complaints, reflecting real problems,
 > > are the following:
 > > 
 > > (1) It was never clear whether proplib is supposed to be a data
 > > *transfer* API (that is, data lives in application data structures and
 > > gets loaded into and out of proplib only for shipment) or a data
 > > *storage* API (that is, data lives in proplib and applications use
 > > proplib to access it). As a result of this proplib has aspects of both
 > > these things and is a good solution for neither.
 > 
 > According to this definition, I have to come to think of it as a
 > data transfer API of a very narrow type: essentially it is one for
 > transferring in one "bundle" several datums of the sort that sysctl(3)
 > moves between the user and kernel.

Yes, this is exactly what I've been trying to express.

 >  Now, what to call that?  A MIB?

Good question... perhaps so.

 > Anyway, I've come to think of sysctl and proplib as both unnecessarily
 > hard to use *and* redundant with each other.

Sort of. They don't fully overlap; given a bundle as described above,
the sysctl(3) API is something like a query interface for it. But not
a very good one. Nor is the numerical and hierarchical MIB structure a
good data model.

There are a number of *ctl(8) utilities that do things similar in
appearance to sysctl(8); many of them have their own custom backends.
Cleaning all this stuff up to share one common representation and
addressing model has long been a goal. It might be possible to
actually do that using a proplib replacement.

There's a further complication, namely that a number of things
retrieved with sysctl(3) need to be retrieved reasonably fast...

-- 
David A. Holland
dholland%netbsd.org@localhost