On 9/6/2018 3:47 AM, Andrew Fish wrote:
Laszlo,
gEfiMemoryTypeInformationGuid is an edk2/MdeModulePkg concept used to
give the DXE Core hints on how to reduce fragmentation in the memory
map. Typically there is code in PEI that creates a HOB and may consume a
variable written by the BDS. This library seems to be the generic way to
do it on an edk2 platform.
Thus this library is not just PI but edk2 MdeModulePkg specific in some
of its assumptions. In general this UefiBootManagerLib seems focused on
construction and edk2 BDS. It would probably make more sense to break
out the UEFI Spec related bits so they could be used in generic UEFI
Applications.
Thanks,
Andrew Fish
Andrew,
I agree refactoring UefiBootManagerLib to separate the pure UEFI, pure
PI and EDKII specific looks much more cleaner.
So far the PI related bits in UefiBootManagerLib may include:
1. Hob access for S4 support (memory type information HOB).
2. Boot from Firmware Volume support.
But that requires introducing two or more library classes so affecting
all existing platforms. EfiCreateEventLegacyBootEx() in UefiLib also
touches PI event gEfiEventLegacyBootGuid.
And I think the value of refactor might be small.
I think root cause of this problem is not UefiBootManagerLib includes
PI, it's the assertion in DxeHobLib.
So I am thinking maybe a very light fix is to remove the constructor of
DxeHobLib.
I talked with Liming about this and he suggested that instead of
removing the constructor, it's safer to just remove the assertion in the
constructor. Because removing the constructor of HobLib may cause
AutoGen process generates a different order of library constructors
calling sequence, which may break the platform.
So I propose to just remove the assertion in DxeHobLib constructor.
Thoughts?
--
Thanks,
Ray
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
