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

I'd say that that's a violation, then.  if it's looking for a property
that it doesn't know is provided, and by whom, then indeed how can it
know that it's getting the right property?


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

But, in fact, why does it _matter_ where they're defined?  They're
supposed to be defined, and unless there's a bug, they'll be defined
in the right place.

My personal feeling is that the ability to do more bug checking than
this may be desirable.  But I don't think doing a "search here only or
search everywhere" approach is the right thing to get that.  I don't
think that's better than "always search everywhere," because for
simplicity of interface usage and coding, that's what's going to
approximately all of the time anyway (and should happen!).  In this
case, the ability to debug problems like this would never be used.


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

You'd know where it came from, certainly.  But you wouldn't know how
far that was from you.

Really, though, why is this useful information to have?


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

Indeed.  If you're going to use 'inherit' (or 'search' or whatever
people want it called), this is what you have to hope for.

And if it's true, I don't think you ever need to _not_ supply
the 'inherit' flag.


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

I think that could be, yes.

If that's the true expression of your belief, your proposal hasn't
done it justice: the only way it does give you to determine the
association of a property with a specific node (other than the current
one) is rather inefficient.  (you need to search up the tree node by
node.)  If you want to determine assocation of a property with a
specific node, or a node within a certain 'distance' of you, you need
to either return the node it's associated with, or pass an indicator
of how far up you'd like to search.

I could see the latter as being a useful tool to make definition of
property-passing protocols a bit more loose, but not in the 0/infinite
form, and if you're going to loosen the protocols then you _really_
need to be careful with this.



An example of what I mean: if you're talking about searching from an
'sd' device, it might be OK to use 0, 1, or 2 to mean "myself only,"
"myself and my scsi bus" only, or "myself, my SCSI bus, and my
controller only"...  But depending on how things are defined you might
only need 0 or 1 (and I can see little use in using just 0)... and you
should almost certainly never need a search depth >2 but less than
"infinite."

Also, if you do decide to e.g. make targets be real devices, i.e. have
bus, target, lun represented by different layers, then: (a) if you
define your protocols well and are always using "search everywhere"
you can make things compatible, i.e. not have to hack use of
properties at all for drivers which drive luns, and (b) if you do
specifically name depths, you will have to go in and hack things.



cgd