eeh@netbsd.org writes:
> The reason to use `struct device' is twofold: to allow searches for
> properties to trickle up the deice tree, and to allow get_mdprop()
> to locate a property associated with a device from some external
> source, say the OpenFirmware device tree.

For the former, you look up the chain of property containers.  You
have to do this anyway, and can't simply look at dv_parent, right?
(e.g. you could specify a fake device as 'propdev' -- and that's where
you'd get your inheritance from, right?

For the latter, why is the 'struct device' relevant at all?!  I'd
think that the actual relevant bits of information, when looking up an
MD propery, would be the device's properties.  Is that somehow
incorrect?  (What's useful in the 'struct device'?)


I looked at the description you originally posted a little more:

> config_search(9) now takes an additional parameter `propdev' which is a
> pointer to a device which provides a set of properties for devices to use
> during probe.  If `propdev' is not NULL, locator data are attached to it as
> properties, it is passed to the probe routine as the `aux' parameter and
> the value passed in as `aux' is ignored.  The probe routine needs to know to
> cast `aux' to a pointer to a device and extract properties rather than use it
> as a pointer to configuration data.

I'm not convinced this argument meaning swapping thing is a good
idea...  It would be nice -- but may not actually be possible -- to
support both aux- and property-based configuration for a while, after
adoption of this scheme.  It's not friendly to have a huge flag day
for drivers if it can be avoided.

We managed to get rid of this type of bogosity once before...  8-)

I think using a 'struct device' here will only be confusing: people
will undtoubedly thing that it's a real struct device, and bad things
will ensue.


> If a non-NULL `propdev' is passed in to config_attach(9), all properties
> attached to it are moved to the newly created device node for the device
> being attached.

s/moved/copied/, right?

Will it be possible to mark a property container as being immutable?
This is important in direct config, where the same property container
is used by multiple match routines, and _must not_ be changeable.


> 	> That would also
> 	> preclude any possibility of implemnting as anything other than a linked
> 	> list in future, such as database table.
> 
> 	Why would it do that?
> 
> For MD properties stored in some other form, say in NVRAM.

Huh?  You'll need to do some more explanation about why using property
containers would preclude use of MD properties stored in NVRAM...

(I wasn't asking why you'd use a table.  I was asking why using
property containers would cause a problem.)



cgd