eeh@netbsd.org writes:
> 	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'.

Except, in order to do this, you need to fake up 'struct device's for
containers which aren't actually associated with devices.

I'm actually really concerned that match functions are going to see
'oooh, struct device!' and decide that they can try to use the
internals.  (There are lots of reasons they might want to try to do
that, all wrong.  8-)


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

Yah -- whether you actually do that, or 'fake it' at first is
something else though.  (i.e. keep the function the same, just cast it
and pass an extra arg.

That's evil, but as a transition thing it may be "OK enough."


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

There's certainly precedent for it (vnodes, etc.), but it's an even
larger change certainly, and would almost certainly need to be done
all at once.

I actually think this might be the right way to go in the long
term... but it's a huge PITA right now.  8-)


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

Right, so, the question is, what does the parent have to redo each
time?  And, how can you prevent match functions from mistakenly
changing properties when they shouldn't?

I think probably the right thing is:

	* when attaching, copy, and

	* let the parent be responsible for marking propdev immutable
	  or not (and, of course, destroying it).

That way, you can do whatever you want, and there are no real
surprises.


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

Of course, you really can't look inside of 'struct device' sanely at
all, anyway.


Anyway, I don't think I care enough about the 'struct device'
vs. other property container issue to continue fighting about it.
Esp. since:

	* the more stuff you put in the property containers, the more
	  annoying they get.  (at this point, you'd need at least
	  flags word and 'up' pointer, as well as a pointer in the
	  device struct to the container.)

	* it seems to me that in the long run, the right thing is for
	  softc data to move into separate structs anyway.


cgd