===== v0.0.12 ==========================================================
Parser/Tools:
=============
-- None; need to be cross-checked against documentation
Documentation:
==============
-- From Darren Hart:
-- Correct language to forbid overriding property definitions via
inheritance
-- Correct revision number examples to remove not-a-number examples
-- Clarify property set revision rules
===== v0.0.11 ==========================================================
Parser/Tools:
=============
-- Updated the tools to reflect the documentation changes below
Documentation:
==============
-- [Robert Gough] db doc:
>>> Section 2.1, I believe the top level directories should not be vendors,
>>> but bus types. The next level would then be vendors, based on the
>>> bus-assigned Vendor ID. For example, bus types would include ACPI, PCI,
>>> USB, etc. Subdirectories would then be bus-specific. So for example,
>>> Intel would own properties under ACPI/INTC and PCI/0x8086. This would
>>> provide an unambiguous mechanism for determining ownership of property
>>> definition.
-- changed in database_rules.txt
-- [Robert Gough] db doc:
>>> In section 2.2, I believe the requirement for "00-base-sets" as well as
>>> the '/' character should be removed from this doc and included in the
>>> 0003-formal-language document, but I haven't gotten there yet.
-- changed in database_rules.txt
-- removed the mention of 00-base-sets as an implementation
detail; there's no real need for us to specify that level
of info to be used by the tools.
-- Explain clearly that "derives-from: B, C" implies an order of use for
>> common names -- e.g., that B/foo takes precedence over C/foo, which will
>> be ignored.
-- changed in database_rules.txt
-- Consensus: overriding a property definition is not allowed.
-- stated explicitly in database_rules.txt
-- stated explicitly in formal_language.txt
-- [Robert Gough] db doc:
>>> Furthermore, I'd like to suggest that using a different scheme for
>>> versioning may be more useful. It may make sense for a given property
>>> set to map to a specification which uses versioning beyond simple
>>> integers, and it may be preferable to have those versions match the
>>> property set versions; so something like 1.3.5 or 0x01030500, for a
>>> major.minor.secondary.tertiary scheme, or something like this <solicit
>>> discussion...>. Also, to go along with this, in section 4 I would
>>> recommend stating that any "new revision" must be greater than any
>>> previously defined revision- such that one cannot create version 1.3.1
>>> after version 1.4 has been defined.
-- relaxed the definition of a revision string to be any C
integer string (0x0, 007, 0b01000010) -- for example,
20150419, 0x01030500, 1.5.3.1, 12
-- added proper text to database_rules.txt
-- added proper text to formal_language.txt
-- Consensus: amendments to the text on making changes need to say:
>>
>> (1) *No* changes to an accepted property set is too strict.
>>
>> (2) Changes to a property set are only allowed in new revisions.
>>
>> (3) Changes to an accepted property set are allowed if either:
>>
>> (a) The change is an obvious typographical error, or,
>>
>> (b) The change is an erratum, meant to correct the property set
>> so that it accurately reflects shipping firmware, or,
>>
>> (c) The change is to an existing data validation rule to make it
>> stricter, which ensures we maintain backwards compatibility.
>> The change cannot not change the types of values, or allow
>> for a broader range of values.
-- added the text above to process_rules.txt
-- added pointer to the text above in process_rules.txt to
database_rules.txt
-- minor rewrites, but content remains the same
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3@xxxxxxxxxx
-----------------------------------
--
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
