some more thoughts on this proposal, from thinking about it some more.

* How do userland programs actually get names for objects?  They
really need to, otherwise how are users presented meaningful names of
objects, to set values?

This made me think, well, you could look up each object's "name"
property or some such...  but there's an inherent race in that, in
that an object could be destroyed (all properties removed) and a new
object created for a different purpose with the same object ID (it's
just meant to be a ptr, right?) in the time between lookup and use of
the object ID.  This might even be 'somewhat common' if you're
manipulating properties for removable, swappable devices from a
daemon...

Sure, other interfaces have inherent race conditions, but e.g. there's
some desire to move away from them in sysctl-ish things, and, well,
why leave the opening if you can do better.

So, that made me think "gee, sure would be nice if 'objects' were
actually named."  Then you could specify database, object name, and
property name as strings, and atomically get an set "the right"
properties w/o fear of object IDs being reused.  (You're probably
pretty safe thinking that if you had an object named 'foo' before and
have one named 'foo' now, it's either the same object, or the current
object is the one you want.)


* you probably want some ability for the kernel to mark some
properties as read-only (not writable even by root).


* you need check and update functions at (probably both of) the
database and/or object levels.

The thoughts here:

	* you might be setting things which have specific allowable
	values (e.g. selected IRQ, etc.), and you want to be able to
	check those before allowing invalid (possibly dangerous)
	values to be set.

	* You could actually use this to do RO checking, but really
	i personally think that's better done with a flag.

	* you might want at both the db and the object levels, so that
	you can cope with changes which uniformly impact all objects
	in the DB, or ones which impact only a specific type of
	object.  e.g. devices: can't ever change device names or
	device 'type's, but perhaps there are some global params you
	can change.  for invididual devices you might be able to
	control various properties.

	* you need the set/update notification functions per object,
	so that objects can keep their own copies of values.
	I can see something like this being used to control e.g.
	runtime parameters of given devices, but the interface is
	not such that you want to do the prop lookup every time
	you're going through some common code path.  instead, you
	want to keep a value cached, and get updates.



So, *plink* *plink* *plink* went my thoughts, and something occurred
to me:

This isn't something that should sit under sysctl, this is something
that should _replace_ sysctl!

These _are_ basically the features we want of a replacement for
sysctl(), except you're missing approximately two things:

* For sysctl, we want hierarchy i.e. to have multiple levels (not just
database,object,property, but e.g. database,object,object2,property;
you want to have 'object' actually indicate another database, so you
again need object2,property to qualify it).

* For sysctl, you can't just have statically-defined property data,
you also need to generate things dynamically (e.g. proc stuff).

Both of those seem fairly easy to accomodate.

If you want to have multiple top-level databases, well, that's
interesting.  What are the ones other than that for sysctl "sysctl and
stuff that sits beneath it"?  Since right now you're presenting them
all under a single sysctl tree it seems that everything could fit into
a single tree...

It's easy to do compat from old sysctl to new: each MIB number in the
old translates to a string in the new... probably can even use bits of
the name/number stuff that's already there... just backwards from how
it's currently used.  8-)


So, at this point I'm thinking, instead of doing this thing that's
about two thirds of the way and most of the coding to the "sysctl we
actually want," why don't you just _do_ the sysctl replacement?

Looking at the "discussion" of this, I haven't seen much commentary
from "people interested in NetBSD APIs" other than myself.  I don't
know why that that is...

Really:

* I think if you're going to pursue this, you're really best doing it
as "the better sysctl" and include the features that are desired,
rather than doing it as "database plus hack on to side of sysctl," and

* I think other NetBSD API people probably should buy in, whichever
way you go.


Anyway, I've spent way more time discussing this, and previous
propsals, with you than i really have time to do.  I don't think I
have any more comments on this than i've given so far...



cgd