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

While I agree that sysctl needs to be replaced, I don't think that this
is the appropriate replacement.

The sysctl() interface is used to expose kernel structures to userland
utilities.  These structures often have highly dynamic, volatile data.

Generic Properties is designed to provide a repository for information
being shared between different kernel modules.  It is not designed to
handle particularly volatile data.  And it is not really meant to be
accessed or manipulated from userland.  It is certainly not suited to
supply data that is generated on the fly, such as the list of active
PIDs, or process arguments.

As I have stated before, replacing sysctl is well beyond the scope of
this project.  That's why I am using sysctl to access the in-kernel
data, rather than creating new system calls that are more suited to
the job.

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

Well, if you prefer to use the filesystem analogy, the database is the
filesystem, and the objects are equivalent to the inodes.  And, most
importantly, directories are plain files, or in this case, properties
attached to objects.

To do what you want, which is have a heirarchical namespace, requires
additional outside the datastore to map objects to names.

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

The original purpose for the datastore was to allow properties to be
associated with device nodes.  Then Jason mentioned he had some application
for properties which did not involve device nodes.  I thought they could
be used for storing such things as routing information, the state of
network interfaces, etc.  

The reason for multiple top-level datastores is to prevent naming conflicts 
between different users.  After all, you really wouldn't want to have
your routing information get mixed up with your device tree information
and accidentally start routing packets through the audio driver.

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

I doubt it does even half of what we want the sysctl replacement to do:

	* There is no human-readable namespace

	* There is no heirarchy.  It is a flat database.

	* It does not really handly dynamic data.  (Although, if you
	  supply your own data buffer for the property you can change 
	  the data whenever you want.)

	* It does not have a real userland interface.

	* It has no concept of protection or permissions at all.

In fact, this is a datastore, not a kernel-userland interface, of which
it would be a consumer.  If you were to replace sysctl() you would design
a new user/kernel interface, of which Generic Properties would be a consumer
just as it is a consumer of the sysctl interface at the moment.

Or, more to the point, sysctl() is a userland-kernel interface, while
Generic Properties is a kernel datastore.  It is questionable whether
you want to implement sysctl() through a datastore or have each user
of the interface supply its own data when requested.

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

There are "NetBSD API people"?

Eduardo