Hi Al Thanks for posting this! One other minor comment is that given section 8 repeats and expands the content of "_DSD Property Database Ruleset" section 4, maybe to make life easier, you should strike the latter and put a reference in there to this section? Cheers Charles On 29/06/2016 00:08, "Hart, Darren" <darren.hart@xxxxxxxxx> wrote: >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 > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
