eeh@netbsd.org writes:
> Here's a revamped vversion of the device properties proposal:

So, you may hate me for this, but another thought occurred to me:

Really, really, really, these things _do_ need to have types.

As far as I'm concerned, the largest reason to try to go with
properties is so that 'random things' can get at them and meaningfully
use them, e.g. sysctl an extension of kernfs.

Unless you know what the actual types of the values are, though,
that's impossible.


In particular, i'm thinking of at minimum:

* 32-bit (or wider, but only guaranteed to be 32-bit) integer (unsigned?)
? 64-bit (or wider, but only guaranteed to be 64-bit) integer (unsigned?)
* string
* paddr_t
? vaddr_t
* bus_addr_t
* bus_size_t
* bus_space_tag_t
* bus_space_handle_t
* bus_dma_tag_t
? ofw node (or something like that)
* 'unknown'

things with ? next to them are for things that i don't know are
needed, yet.  8-)

single name space, but qualifed for sanity.

When looking things up or changing them, you should probably be forced
to provide the type information, just to be sure.  in lookup or
change, 'unknown' would match any of the known types, plus 'unknown'.
(change of an existing value to unknown wouldn't change its type.)

The notion being here if you define a new type (e.g. say you want a
special type of pci_chipset_tag_t or whatever), code which doesn't
know about it can continue to work, but code which knows about it can
be a bit more careful to get the right thing.

(You can then call back into MD code to translate from those to sysctl
types, or maybe you could do it from generic code for most...)


cgd