Subject: Re: Device Properties: The Next Generation
To: None <eeh@netbsd.org>
From: Chris G. Demetriou <cgd@sibyte.com>
List: tech-kern
Date: 02/20/2001 09:50:08
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 already have a file system.


> 	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?

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).


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 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 can't really pick both at the same time...



cgd