Subject: Re: Device Properties: The Next Generation
To: None <email@example.com, nathanw@MIT.EDU>
From: None <firstname.lastname@example.org>
Date: 02/21/2001 23:44:38
> 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.
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'.
The authors of different devices are likely to be different
and may very well decide to use properties in manners that
can conflict. In addition, there are properties provided
by firmware, and even users will be able to add arbitrary
properties to arbitrary devices by editing the config
files. I don't think that there is much that can be
done to solve this problem.