On 08/16/2016 03:23 PM, Al Stone wrote:
On 08/12/2016 05:51 PM, Hart, Darren wrote:
> On 8/12/16, 4:39 PM, "Wysocki, Rafael J" <rafael.j.wysocki(a)intel.com>
>> On 8/13/2016 1:31 AM, Hart, Darren wrote:
>>> One more comment for 0002-database-rules (and I’ll send a patch at least to
the TODO file for these two I have outstanding).
>>> Section 2.2 Inheritance is problematic in my opinion.
>>> On the one hand, it says :
>>> “However, if two
>>> or more base sets contain a property with the same key, the derived set
>>> inherits the property from the first base set listed in the definition
>>> of the property.”
>>> But goes on to say:
>>> “Direct definitions of properties in the derived set cannot override
>>> any properties inherited from the base sets.”
>>> But the workaround to this is to simply include a set that has the override
>>> Instead of (this doesn’t follow the formal language, but gives the idea):
>>> Inherit A
>>> Where A also defines foo, so C is illegally override it, you would do:
>>> Inherit A
>>> Inherit B
>>> Now C overrides Apple from A. So the rules do a poor job of enforcing the
>>> I suggest we either:
>>> 1) Forbid overriding, inheritance must be of disjoint property sets (no
overlapping properties), which in turn means that order of inclusion no longer matters.
>>> 2) Allow overriding in the property set definition itself and change the
rules to use the LAST definition of a property, rather than the first.
>>> I personally prefer #1. It’s simpler.
>> That's correct, but it may be practically inconvenient, for example when
>> two sets you want to inherit have one property in common.
>> That may be addressed, though, by requiring that any overlapping
>> properties in the inherited sets must be identical.
>>> It also matches what will happen with the OS driver (unless we want to see a
host of quirks for every overridden property of a common set).
>>> I’d appreciate your thoughts everyone before I submit the TODO patch.
>> I think we can go for #1 with the above modification, unless you see a
>> problem with it.
> That seems reasonable to me.
Sorry for the delayed reply.... I'd prefer #1 also. Whether or not that is
practical is a different question, and I think some experience with this over
time will provide us the right answer. But, let's try it for now and see if
becomes a limitation or not.
Hey, Darren. Just a gentle ping; do we have a time frame for we can expect
Red Hat, Inc.