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

Yeah, that would work.  (Although I hate the syntax for cating
pointers to functions 8^)

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

I think that the interfaces I have proposed should be able to handle
this transisiont with little or no changes.  It would be nice if I
could say the same about the rest of the kernel 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.

Sounds reasonable right now, but if we separate out the 
`struct device' from the softc then the propdev is transformed
into the real device at attach time.  This means we need to 
add code to config_attach(9) to detect an immutable propdev,
create a replacement propdev and copy the properties from
the old old device onto the new propdev, and finally return
the new propdev to the parent to use for the next attachment.

I think it would be much easier in the long term to say that
after an attempted attach the propdev is in an undetermined
state and the parent should re-initialize it.  Yes, it wastes
a small amount of processing power, but simplifies the other
issues.

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

Yeah, I originally thought it would be too much work but now
it seems to be the only really clean solution.  Seems a bit 
much for 1.6.  It would break *EVERYTHING*.  How do we migrate
there?  We could have devices that use `aux' have monolithic
device structures and the others use a separate softc, but
that would have to be based on the parent bus which registers
the properties and preclude devices that can attach to both
types.

Eduardo