eeh@netbsd.org writes:
	> I still don't get it.  Could you give an example where limiting
	> a property to `x' levels below this node would be useful?

	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.

	Certain cases, e.g. the power management one, seem to call for
	properties to be inherited by any children.

I think this is a semantics issue:

The search for the property is using inheritance, but the 
property is not being inherited.  If the property were being
inherited, then the property would be duplicated in the device
node being queried, which it is not.  PROP_INHERIT is merely
a convenience for the case where it would be necessary to
look for properties in nodes higher up the tree.

	However, in other cases that behaviour seems completely bogus:
	e.g. why _should_ a SCSI disk be able to inherit e.g. PCI chipset info
	from the PCI controller N levels above it, or even the PCI device
	number of the controller it's hanging off of M levels above?

	Attempts at such uses are erroneous, even if an explicit attempt to
	inherit the property is made.  Why?  Because the SCSI disk shouldn't
	care, and can't really know what it's attached to N levels up.  All it
	knows is the defined interface between it and its parent.

	Attempts to get at such data are violations of the interface the SCSI
	disk should be attempting to use.  If it has some type of special
	knowledge, e.g. by grovelling around device structures and looking
	explicitly at its parent, it can find out more.  But, barring that, it
	shouldn't be able to just fall on additional data.

	A good properties interface will make it straightforward to find and
	diagnose such simple violations.  In a nutshell, to my mind, that
	means at least being able to specify the extent to which the data
	should be propagated.  (That way, if somebody looks, and they can't
	find it, they get an error at least, rather than getting data that
	they shouldn't know what to do with.)

	The 'limit inheritance to N levels' seemed a method of doing that
	which is simple in both concept and implementation.


	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.  I expect
it will eventually be legible in userland, since I forsee building
userland property tree extractors, which would be useable in
the creation of custom kernels.

If you want to publish some data you want to keep private, then
you need to use some outside form of security, say publishing
a pointer to some opaque data structure that only the interested
party knows the structure of.

This is all going inside the kernel.  While some of these features
may be interesting from a debugging or diagnostic point of view,
they really don't belong in a production kernel.  I don't think we
want to pay for this unnecessary extra complexity and overhead.

Eduardo