eeh@netbsd.org writes:
> | 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 for every piece _except_ 'object's.


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

There certainly is hierarchy described by the structure you've
proposed.  There're at least three levels: "database", "object", and
"property" eh?


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

You can't really do the latter, though, since others can set the
property and then you'll have no notion of that change (and others
won't see anything, if you change your data buffer).


> 	* It does not have a real userland interface.

You gave it a sysctl interface...


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

I don't know how much of these we need a sysctl replacement to do.

But, this begs the question:

Without any form of protection or permissions, how is it safe to
export this via sysctl at all, let alone making it writable via
sysctl?


> In fact, this is a datastore, not a kernel-userland interface, of which
> it would be a consumer.

Sysctl is two things: a user/kernel interface to get data, and the
data store behind it.

You've created an entirely new data store, and effectively tried to
glom it on to the existing data store and interface.

We don't need an old sysctl data store, a new properties data store,
an old sysctl interface, an old sysctl interface that includes
properties, and, eventually, a new sysctl interface.

We should have _one_ data store that's flexible enough to handle both
sysctl's existing uses -- which isn't that hard -- and the dynamic
naming needed for properties.  In fact, we've recognized the need for
real dynamic naming support in sysctl ... many times over the years.

Maybe if you were proposing this N years ago, it might seem more
reasonable as an add-on to sysctl, but it's been long accepted that,
really, sysctl in general needs an extension to do dynamic naming.
The thing you're trying to stuff on the side isn't anything other than
an evolutionary dead-end.


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

sysctl has:

(1) static name space.

(2) 'static' data elements that are read-only.

(3) static data elements that are read-write with an update mechanism
so that code is notified of changes.

(4) dynamic data.


On the other hand, generic properties has:

(1) dynamic name space

(2) effectively-static data that should be treated as read-only (with
no provision to make sure that it's not written).

(3) possibly-writable data, but with no notification of updates when
written.

As far as I can tell, generic properties as described provides storage
of data that pretty much has to be read-only, since there's no
update-notification mechanism.  (What's the use of changing the data,
if nobody notices that it's changed?)

It provides no particularly good way to read or write that data from
userland (since it doesn't provide names for objects, you still have
to grovel somewhere to find what an object is, which is "not good").


I don't see how this is _not_ an evolutionary dead-end.  When sysctl
is enhanced to be "better", what functionality that you provide in
generic properties _would not_ be subsumed into an enhanced sysctl?
And, how would going here first do anything but make people churn
their code twice?

Better to just do it right up front.  It's really not that hard.


> There are "NetBSD API people"?

Yeah.  People with interest in NetBSD APIs, at least some of whom
you'd expect to respond to e-mail messages like this on tech-kern.


Anyway, I'm done with this thread.


cgd