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

No, it's flat, except for the database, I suppose.  A property is
("object", "property") and retrieves a ("type", "value").

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

I suppose that depends on the sensitivity of the data stored in it.
The same question is applicable to any of the rest of 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.

No, quite the opposite.  The data is held outside of sysctl, only an
interface to access that data is managed by sysctl.

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

Once again, this is not an add-on to sysctl.  It merely uses sysctl to
export the data to userland, the same as the scheduler, uvm, the message
buffer, etc. do.


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

I'd expect that if you want event notification you should be using 
kevents/kqueues for it, not properties.

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

Properties were not supposed to provide sysctl-like functionality.
They were supposed to provide an extenisble method of storing and retrieving 
data inside the kernel, without requiring knowledge of the data structures
to percolate throughout the kernel.  In fact, the original version did
not have any userland interface at all.

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

Promise?

Eduardo