On 02/14/16 10:22, Ard Biesheuvel wrote: > On 14 February 2016 at 07:51, Laszlo Ersek <ler...@redhat.com> wrote: >> On 02/14/16 06:44, Yao, Jiewen wrote: >>> HI >>> Thanks to discuss this properties table issue. >>> The purpose of this patch is to *add* UEFI2.6 memory attributes table. This >>> patch does not handle any UEFI2.5 properties table. >>> If we want to change EDKII code for properties table, I suggest we separate >>> it from this patch. >>> >>> Is there any comment for adding UEFI2.6 memory attributes table? >> >> Not from my side, thanks. >> >>> For UEFI2.5 properties table, let me summarize. Currently, we have several >>> options: >>> 0) Keep it as is. Current setting is PcdPropertiesTableEnable TRUE in >>> MdeModulePkg.DEC. >>> 1) Update PcdPropertiesTableEnable to FALSE in XXXPlatform.DSC file. >>> (Platform choice. It can be static PCD or dynamic PCD.) >>> 2) Update PcdPropertiesTableEnable to FALSE in MdeModulePkg.DEC file. >>> (Disable Default. BIOS will not publish this table by default. If platform >>> wants this table, it can set PCD to true.) >>> 3) Remove PcdPropertiesTableEnable, and remove PropertiesTable support code >>> in DxeCore. (PropertiesTable support is removed.) >>> >>> Personally, I do not suggest we choose 3), because this table is still >>> defined in UEFI specification. We can remove it after UEFI spec removes it >>> later. >>> I do not have strong opinion for other options. >> >> I agree the implementation should follow the spec -- at least offer the >> feature as long as the spec defines it. My vote would be (2). >> > > I disagree. Not only was the PropertiesTable superseded by the > MemoryAttributes table in 2.6, the recommendation not to use the > PropertiesTable has also been added to 2.5 errata A, while it was > originally defined in 2.5 This means effectively that it has been > retracted, and so it does not matter if you claim to implement UEFI > 2.4, 2.5 or 2.6, in none of these cases should the PropertiesTable be > published.
Well, why not drop the text from the spec completely then? > The reason that the definition remains in the text is for the OS side, > not for the reference implementation of the firmware side, which > should steer clear from it entirely. Okay, but in that case, I sort of think of the edk2 code as something that would let you test an operating system's support for this (mis)feature. Anyway, I don't disagree with (3) either. If that is what gets implemented, I'll be fine with it. As long as there's a way to disable the (mis)feature -- by way of PCD or complete removal --, I'm okay. Thanks Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
