[...]
	> 	I disagree with this.  A device should _never_ have to look directly
	> 	at another device's 'struct device' in order to function properly.
	> 
	> Then why are we passing a `parent' pointer into the driver *match()
	> and *attach() functions?

	You know, that's a good question.  I think the reason why we do it is
	because that's they way the code was when it came into our hands, and
	we never modified that part of it.

	Certainly, now that I think about it, nuking that is something to
	consider.  (it could be a difference encapsulated old-style
	vs. new-style in the cfattach/fn wrapper macros that have been
	discussed previously, to allow a smooth transition.)

I really don't want to get involved in this issue.
If you think that we should get rid of the parent 
pointer passed in to the *match() and *attach()
routines, please put together a separate proposal.
It really is orthogonal to device properties.

[...]
	> 	> If you use inheritance you never know who's property you're getting.
	> 	> The parents are not the ones who care who's reading which property.
	> 	> It's the children who can't trust the source of the property, whether
	> 	> it comes from some parent node or some machine dependent repository.
	> 
	> 	Again, if this is true, what's a real-life example of a problem that
	> 	_isn't_ a 'protocol violation' bug?
	> 
	> See above.  This is for much more than just attaching 
	> devices to buses.

	Sure.  But the point is, that example in the context of NetBSD is one
	of a protocol violation and I think just about any similar one would
	be.

	The child was expecting to find a property from a predecessor in its
	tree, that the predecessor erroneously did not provide.

	In the OFW world, where you have to worry about backward compatibility
	with old OFW, then maybe it was a problem.  But this properties scheme
	is _not_ OFW.

	If there's going to be a defined property-passing protocol between
	parent, child, grandchild, etc., then it should be defined and stuck
	to.  That means, for instance, consistently making sure that
	e.g. "frequency" is there if children or grandchildren expect it.

A device can attach to multiple different buses.
Each bus may require different properties to attach
children.  They may conflict.  

	> No.  Properties are for much more than just attaching
	> child devices.  They are for controlling driver behavior.
	> There will be many properties that will be used by device
	> drivers that the bus drivers will know nothing about.  

	Sure.  And those have to be defined by a system-wide protocol, rather
	than a simple parent-child protocol.

Are you saying that we need to define a global 
protocol for all possible buses, even ones that
have not been designed yet, initially, so that
no properties can conflict between them? 

[...]
	> This is not just replacing locators and `aux'.  It also
	> replaces `flags' amongst other things.

	Right.  That seems fairly straightforward.

	For flags, you need to enumerate up front (e.g. in the config file)
	what the possible flag-replacement options are.  If an option is not
	specified, the default value should be provided.

So every time that a driver wants to add a new
property to, say, turn on debugging, you need
to edit `files' files to add in a default?  I
suppose it could be done, but it seems a bit
restrictive to me.

[...]
	(2) you need some way to limit the scope of use of protocols.  And,
	I'll again assert that, if you're going to do that, "0 and many"
	aren't sufficient.  e.g. limiting scope to grandchildren is quite a
	reasonable thing to want to do.  (scsi ctlr, scsi bus, scsi device...
	or, if somebody ever fixes the SCSI code to attach targets rather than
	target,luns, you'd need great-grandchild...)

I'm still interested to know how you would implement
a protocol that is more complicated than "0 and many".


	> Also, some of the properties involved in a protocol
	> may be set by the parent driver, but others may be
	> set by firmware or inside the config file.  If we
	> try to control inheritance when properties are added,
	> we can only control the inheritance of properties that
	> were added by drivers at run-time.  

	That's true, yes.  Which, I think, speaks to the need for defining the
	property communication protocol well and doing completely away with
	any worries about the need to inheritance.


	At this point, i've pretty much punted on the notion of limiting the
	inheritance, at the creation or lookup side.  If you define your
	properties well, and make sure they're passed at the right places, you
	shouldn't need it.  (It was you, asserting that indeed that was what
	removed the need for inheritance limitation, that got me thinking down
	that path...  8-)


	It's worth re-emphasizing that your proposal specifies the mechanism
	for looking up properties, but doesn't actually say what properties
	should be looked up, should be passed down from parents, should be
	globally defined, etc.  Those things really should be subject to
	another discussion entirely, but really come after the definition of
	the interface, to my mind.

Now you have completely lost me.

You are saying that we should always do a full depth search
for properties and not allow a single query to determine if
a property is associated with a specific device node?  

Hm.  O.K.  We could do that....  So if you need a property
attached to a particular node you could search that node, 
and it's parent, and if it's on that node but not its parent
then it's on that node.  You also need to compare values to
make sure they are the same.  It will be less efficient, and
if the node you want *and* some ancestor have identical values
then you will think that the property is not attached to the
node you want....

Although, getting rid of the depth search feature would be
more flexible in the long run.  It's much easier to implement
the depth search with a single node search than to implement
a single node search with a depth search.

Eduardo