<eeh@netbsd.org> writes:

	> The property is not overloaded; it is the same property
	> but associated with a different device.  The location of
	> a property is part of the semantics.  We are not talking
	> about OOP here, we're talking about filesystems and `find'.

	If it's not OOP, don't call it "inheritance". Inheritance implies OOP
	to many people. Don't do that unless you *want* to be confusing.

O.K.  Fine.  The term `inheritance' (which is inherited
from Solaris, BTW) is causing too many problems.  Consider
it officially renamed to `search' and the flag will now
be called `PROP_SEARCH'.

	If it's a filesystem, use "..". Have devices look up "../propertyname"
	and not rely on magic level-propagation hacks.

That's an interesting concept.  There are several issues
with it:

	1) it makes the code more complex.
	   Reimplementing a namei() that works
	   on device nodes will be painful.

	2) just using "../propertyname" does not
	   help if you don't necessarily know where
	   the property resides, so you still need
	   `PROP_SEARCH'.

	3) the names and locations of device nodes 
	   vary, so a hard wired "./foo0/reg" will
	   not work if there is no "./foo0" device.

	4) going down the device tree is difficult
	   since to find a child of a device node 
	   you need to search the global device list
	   and look for a device who's parent pointer
	   matches.

	5) because of 4, wildcarding will be very
	   difficult to implememnt.

With the current proposal, all these operations would
be implemented by the requestor walking the device tree
himself.  

While allowing the use of strings to specify paths
in the style of a filesystem may look prettier, it
turns out harder to implement both inside the interface
and in the code that needs to generate strings at 
runtime to query the interface.

Eduardo