Subject: Re: Device Properties: The Next Generation
To: None <firstname.lastname@example.org, email@example.com>
From: None <firstname.lastname@example.org>
Date: 02/20/2001 00:39:28
> 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
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.