Subject: Re: Device Properties: The Next Generation
To: None <email@example.com, nathanw@MIT.EDU>
From: None <firstname.lastname@example.org>
Date: 02/22/2001 18:59:51
> 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
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
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
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
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.