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?

The property containers have been, up to this point, `struct device'.

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

`struct device' is a uniquely identifyable entity that can be used
to query properties against.  Otherwise you need some other form of
identification for the particular device instance.  And major+minor
is not a good way to go.

	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.

That could be done, but would require changing the signature of
the probe function to take both an `aux' and an entity that can 
be used to query for properties.

	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.

We could do what solaris does and separate out `struct device' from the
softc.  What they do is generate a tree of device nodes that do little
more than define a heirarchy and hold properties.  Then, when a device
attaches, a softc is allocated for it and attached to the device struct.
That way the `struct device' could be allocated and used for properties
before the type of device, hence the size of the softc, has been determined. 
This also did not seem such a good idea at the time.

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

Right now the properties are removed from the null device to the
real device.  The reasoning is that when attaching devices, there
are usually changes in the `aux' structure corresponding to different
locations on the bus.  This behavior could be modified to copy the
information, and I suppose some worm of immutability could be added
if it would be useful.

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

Excluding the issue of the device tree (and I really don't like the
idea of having two of them, one for `struct device' and another
for `struct propdev', but I digress) this has to do with the 
implementation of the get_mdprop() routine.  It may not be an issue.  
The OFW version would probably extract the "node" property from 
the property container and use that to query the firmware.
I really don't know if other implementations could get by from
extracting properties or need something else that can be accessed
from the `struct device'.

Eduardo