Subject: re: Device Properties: The Next Generation
To: Nathan J. Williams <nathanw@MIT.EDU>
From: matthew green <mrg@eterna.com.au>
List: tech-kern
Date: 02/22/2001 12:15:36
my feelings on property inheritant stands pretty close to eeh's:  don't
restrict the way properties can be used to try to avoid programmer lossage.
with these restrictions, they become much less useful.

   
   > A cartain Solaris SCSI controller device driver wanted to know the
   > chip's clock frequency.  There were several versions of this chip at
   > different clockrates, and the faster ones were capable of faster
   > transfers.  So if it was running on a fast chip, the driver would
   > enable the higher speed transfers.  To make this determination, it
   > queried the `frequency' property.  However, some of the older
   > devices did not have a `frequency' property in the FCode for that
   > node.  Since the request had specified PROP_INHERIT, it would match
   > the `frequency' for the bus on some machines, which was not the
   > right value.  This caused the driver to use the wrong settings and
   > caused problems.
   
   This problem is caused by overloading the property name
   "frequency". Avoiding namespace shadowing by selectively adjusting
   scope feels very messy. If you want properties of different devices to
   have different semantics, give them different names.


how can you suggest restricting who can use what name?  why should one
particular bus/device/protocol get the glory of owning any particular
name?  that doesn't extend.  (and i'm sure we don't want to introduce a
real `namespace' attribute with it's own inheritants issues.  :-)


.mrg.