eeh@netbsd.org writes:
> 	Here's a question: why support PROP_INHERIT at all?
> 
> 	i.e. why not _always_ inherit from parents?
> 
> Most of the time you want to query a particular device's
> properties, usually yourself.  Should I use TAG QUEUEs?
> What is MY interrupt number?  What is the physical address
> of MY registers?  What are the limits of MY DMA addresses?
> You do not want this information from your parent because
> it is likely to be of little use.  And, if you don't have
> the property but some ancestor does, and you start to use
> it as your own, this can have disasterous effects.

Right, but, haven't we previously covered this?  The protocol between
parent and child says what has to be provided at each level, and what
can be inherited, right?

So, it should always be safe to _try_ inheritance, right?  It will
only succeed incorrectly if a parent has _not_ provided something that
it should.

For instance, in the case of tagged queueing:

	(1) if there's a local setting, you _do_ want to use it,

	(2) but if there's not, you want to fall back on the default
	    (e.g. to disable it globally),

correct?  (the global default might be a tri-state switch, enable,
disable, default, even.)

For most of the things that you describe (interrupt number, physaddr,
DMA addresses), providing those is part of the parent->childe property
passing protocol.  The other is inheritable, but also settable by the
parent.

What's a case where you could inherit a property incorrectly, that
_wouldn't_ signal a violation of the property-passing protocol?


> 	It seems to me what you have right now is:
> 
> 		"0, many"
> 
> 	I.e., you search only your locally attached properties, or you search
> 	the entire tree up to the root.
> 
> 	It seems to me that that's missing the classic "1" (or a more abstract
> 	version of that).
> 
> The `classic "1"' is a query of your direct parent without PROP_INHERIT.

I disagree with this.  A device should _never_ have to look directly
at another device's 'struct device' in order to function properly.


> 	If your claim is, the protocol is defined and can be followed to
> 	correctly produce a property using inheritance, then you shouldn't
> 	need to specially turn on inheritance.
> 
> 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?


> 	If your claim is that you _should_ need to specially turn on
> 	inheritance, then you're missing support features that I think are
> 	important: some way of limiting the inheritance in cases where it's
> 	"known" (by the protocol) not to be desirable.
> 
> You do not `specially turn on inheritance'.  You are doing 
> queries that either do or do not continue up-tree.  This is
> not something that can be limited at the producer side because
> the producer does not usually know the consumer's information
> requirements.  

Huh?  The procotol between parent and child means that indeed, the
producer can and _does_ know the requirements of the child/consumer!

It may not know them all the way down the chain... but that's the
whole point.  It shouldn't be (effectively) passing things all the way
down the chain unless it knows that protocol!

Which was the whole genesis of the notion of limiting how far
properties can be inherited.


> 	You can't really pick both at the same time...
> 
> The only reason to have inheritance is to simplify programming.

The point of my question was the only one of the following can really
be true:

(1) you need some form of limiting inheritance at the source, or

(2) the protocol at each level takes care of the problem.

You have been asserting the latter.

If you assert the latter, it seems reasonable that PROP_INHERIT should
_always be on_, i.e. inheritance should always happen.

If not, then really that's a statement that, for each level, the
inheritance protocol is not as well defined as it should be.  And one
of the things that falls out of that is that devices might then
reasonably want to be able to define how far their properties flow.


I.e. I understand why you want PROP_INHERIT.  I don't understand why,
assuming the protocol for passing properties is defined as well as it
should be, you'd ever need to _not_ use it.




cgd