Re: [RFC DSD 01/03] _DSD Property Registration Ruleset

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks Al,

On 6/28/16, 1:07 PM, "Al Stone" <ahs3@xxxxxxxxxx> wrote:

…

>8. Immutability of Registered Property Set Definitions
>------------------------------------------------------
>All property set definitions, once registered and in the database [2],
>are immutable. It is not possible to remove existing content from the
>database or to modify any of it in place.  It only is possible to add
>new content.
>
>The only way in which one property set can be superseded by another one
>is to register a new revision of the property set in question.
>
>Moreover, when creating a new revision of a property set, it is invalid
>to redefine property keys (that is, associate them with different data
>types or give them different meaning).  New revisions can only add
>properties to the set or remove them from it.  If one of the properties
>in the current (most recent) revision of a property set is to be
>deprecated in the next revision, the correct way to do that is to remove
>it from the set entirely and define a new property with a new key as a
>replacement for it.
>
>If there are multiple revisions of a property set registered, platform
>firmware is required to provide properties from the most recent one.
>However, for the sake of backwards compatibility with existing Operating
>Systems, it may also provide properties that are not present in the most
>recent revision of the set, but were present in the previous revisions
>of it.
>
>Operating Systems are required to use properties from the most recent
>revision of a property set they are aware of.  However, if those
>properties are not provided by platform firmware, the OS may fall back
>to using properties from the previous revisions of the property set that
>are not present in the most recent one.

The wording “…or remove them from it” is problematic. In order to ensure backward compatibility, we need to ensure that new revisions do not remove required properties from previous revisions.

The goal is for an older OS/driver that only knows about revision 1 to continue to function with revision 2 by using all the required fields, and ignoring the additional fields added by later revisions.

I’d recommend we strike “ or remove them from it” from section 8.

-- 
Darren Hart
Intel Open Source Technology Center

��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f




[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux