On 04/05/16 19:46, Andrew Fish wrote: > >> On Apr 5, 2016, at 10:26 AM, Jordan Justen <jordan.l.jus...@intel.com> wrote: >> >> I don't think it conflicts either. >> >> I wonder if Mike or Andrew have any thoughts about why the ACPI >> includes (and arguably EDK II) go out of their way to define flattened >> (duplicated) structures for different spec versions. >> >> Once again, I personally don't mind the sub-structure based on >> versions if Mike and Andrew don't have anything to add... > > Jordan, > > I'm not sure why things like GENERIC_ADDRESS_STRUCTURE keep getting > redefined even though the definition > EFI_ACPI_5_0_GENERIC_ADDRESS_STRUCTURE is the same as > EFI_ACPI_5_0_GENERIC_ADDRESS_STRUCTURE.
I apologize for repeating my speculation / suspicion from my other message, but, again, I believe it was coded up like this simply because a straight trans-coding of the flat member list, from the spec, into C source, was easier and less error-prone for the developer, than laborously locating inter-version identities, and extracting them as common sub-structs. Using your example, in ACPI 5.1, "Table 5-26 Generic Address Structure (GAS)" is just a list of fields; it doesn't say "this structure is unchanged relative to ACPI 5.0". So the developer goes ahead and codes up EFI_ACPI_5_1_GENERIC_ADDRESS_STRUCTURE straight from the 5.1 spec, without looking at EFI_ACPI_5_0_GENERIC_ADDRESS_STRUCTURE. I think. > Some things are actually different, for example > EFI_ACPI_5_0_FIXED_ACPI_DESCRIPTION_TABLE has more entries than > EFI_ACPI_4_0_FIXED_ACPI_DESCRIPTION_TABLE. > > Maybe Mike remembers the reason? > > Seems like changing it now risks breaking existing code. Absolutely. I think there is no suggestion to extract common sub-structures now. The question is if we should imitate this open-coding / duplication of fields in new code, when there is every reason not to. (The reasons including: sub-structure extraction is natural, frugal, and standard C, and in this specific case, it even reflects the wording of the underlying specs). Thanks! Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
