eeh@netbsd.org writes:
	> 	So, I think we're looking at this from different angles.
	> 
	> 	I can construct some where you _need_ that behaviour, but they seem
	> 	forced.
	> 
	> 	However, it seems obvious to me that an inherently useful feature of a
	> 	good properties interface would be _not_ exposing data where it
	> 	shouldn't be known.
	> 
	> No, properties are available to all.  If you want to restrict
	> access, then you're building a filesystem.

	This seems like ... a red herring.

	You already have:

	(1) hierarchy,
	(2) naming,
	(3) inheritance (a primitive type of access control, kinda)...

You don't have inheritence.  You only have a heirarchy.  
PROP_INHERIT is merely a request to search up the heirarchy.
It is not access control.  There is no access control.

	You already have a file system.

No you don't, not without access control.

	> 	Really, this kind of interface needs _some_ method of limiting the
	> 	propagation of inherited properties.  I've brought up several; that
	> 	one seems the simplest.
	> 
	> I completely and utterly disaggree.  Properties are a way to
	> publish data to other entities that may be interested in them.
	> This is usually information describing a device node.  If there
	> is any confidential information it should not be placed in a 
	> property, since then it would be readable by anyone.

	It's not a matter of "confidential."  It's a matter of, no need to
	know it, so why expose it and allow the ability to create bizarre bugs
	though weird programming errors.


	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.

This is how I expect it to be used 99% of the time.  

	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.

	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.

	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.  

	You can't really pick both at the same time...

The only reason to have inheritance is to simplify programming.
It allows a device to provide MD properties to descendents
down the tree without having to modify intermediary MI drivers.

Say a bus controller wants to provide the same bus_tag to all
its children.  Without PROP_INHERIT, either the bus controller 
would need to attach the `bus-tag' property to each of its children,
or each child would need to query its parent for the property.  If
a transparent bridge, then either it would need to propagate the
`bus-tag' property to all its children too, or the children would
need to walk the tree themselves.

Concrete example: you have a PCI controller sitting on an OFW
bus.  You also have a PCI driver which needs to query OFW to
get some information.  It needs to have it's OFW `node'
number to do the query.  But there is no way to translate
from PCI bus/slot/function to OFW `node', so want to pass 
the OFW `node' number down the tree so the device can do 
the OFW query it needs.  But, you can't do that now without
modifying each intermediate driver to add that value to
the `aux' it passes.  So instead, the PCI controller attaches
a property with the node number to itself, and the child can
query it, bypassing any arbitrary number of MI PCI bridges or
buses that may be in the way.

That is the reason to use PROP_INHERIT.  To bypass nodes that
have no business being involved in transferring MD information.
That it can be used to limit the duplication of properties
in the device tree is a nice side-effect, but certainly not
it's raison d'etre.

Eduardo