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

	Sure.  However, note two things:

	(1) if you do the macros for conversion as I suggested, it's trivial
	to do at the same time.  Such a proposal is simply a matter of lumping
	in with yours "in addition to the other modifications to the
	match/attach calling conventions, don't pass in the parent device.
	All in favor say Aye."  8-)

	(2) If it is done, it should be done at the same time, so you don't
	redefine the definition of what goes into match/attach twice.  It
	shouldn't hurt to do so, in fact, but it's best to do it just once.

Currently, esp_sbus makes numerous accesses to its
direct parent to acquire information it needs to 
attach properly.  But I suppose that can be worked
around by using the parent pointer in its own device
structure rather than what's passed in the `parent'
parameter.  So, unless there are other objections,
we'll get rid of `parent' at the sime time as we add
device properties.

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

	No.  We have to define a global protocol for all cases that _may
	overlap_.

The bus independent parts of the attach may want to 
test for properties that may not be in the protocol
used by a particular bus....

	As long as you permit inheritance/searching-of-parents, you need to do
	this.

	The only way to avoid it completely is to compartmentalize at each
	level.

	I suggested that previously, it doesn't seem like a great idea though.


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

	Hmm.  Well, mrg seems to mostly share your world-view, but seemed to
	understand what I was saying here.  Perhaps he can explain it to you
	better than i can.  8-)


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

	Sure.  The logic behind it goes something like this:

	(1) For properties that you expect to be directly attached to you, you
	know that they're directly attached (if the value is no, the property
	no is attached, i.e., you don't assume no-property means value == no).
	The sets of properties you expect are defined by your parent-node
	protocol, or node-only protocol.

O.K.  I think we're in agreement so far.

	(2) For properties that you expect to be had by searching, you must
	know before hand that in fact they exist and pretty much where.  The
	sets of properties you can search this way are defined by the
	grandparent-node, greatgrandparent-node, etc., protocols or the global
	protocol.  If you do not know that and where the properties will be,
	your search results can't have useful meaning (because you don't know
	that the value you get applies to you).

Well, you know where they are supposed to be defined,
but unless you search a particular node, you don't know
for sure where the property came from.  This involves
traversing the tree for individual nodes.

Even if the recursive query call returned a pointer
to the node that provided the property, you wouldn't
know where the property came from unless you traversed
the tree looking for that node, since you don't know
how many intermediate nodes may be between you and it.

So you define a protocol and hope everyone follows it
and don't screw up.

	(3) Therefore, following from (1) and (2), for all properties that you
	may access, you know where they're coming from, and that they exist,
	and that they are attached in the right places.

O.K.

	(4) Therefore, following from (3), you never need to specify "search"
	-- you know everything's there in the right places, so you can
	_always_ search and expect the right result.


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

	But the point is, you shouldn't need to do that.

	If you want to know about a property, you're guaranteed that you will
	have information about the property you want, and that it will apply
	to you.


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

	That's the other side of the coin.

	If you're going to do this, i assume that the only people who will
	explicitly make the parent->child jump are those that have in-depth
	knowledge of what their parent is.  If you do other than that, well,
	then you start needing to worry about the whole 'defined protocol'
	issue.

	It has some distinct advantages and disadvantages:

	Advantage:

	(1) you don't have to spend much time worrying about what you're going
	to pass down, since the scope of that passing is very limited.

	Disadvantages:

	(1) it wastes a lot of space on duplication of properties, that could
	otherwise be inherited.

	(2) it means that if you want to set defaults at any level of the
	hierarchy, they have to be passed down to children.  That means you
	know what all possible settable defaults are, and are sure to pass
	them down.

	(3) it means that if you want to _change_ a default that's already
	been passed to children, you have to do a lot of work; you can't just
	update the default, you have to update the copies too.

If I understand this correctly, the argument boils down to:

You argue that if you have complete control over where properties
are allowed to be placed and how they are used, you do not need
the ability to query a particular node for a property.  Since
the protocols in use will dictate where a property is allowed
to reside, you can infer its location by its presence or absence.

I argue that that level of control over placement of properties
is unduly limiting and would prevent the use of (what I consider
useful) semantics of determining the associateion of a property
with a specific node.

Is that correct?

Eduardo