On 2019/3/21 1:47, Laszlo Ersek wrote:
On 03/20/19 13:16, Heyi Guo wrote:
On 2019/3/20 17:55, Laszlo Ersek wrote:
If we don't have to flatten a ridiculous amount of other library code
into the RuntimePrepare() function, I think such flattening would be a
viable approach. We've run into this constructor loop several times
before, and -- if I remember correctly anyway! -- one approach has been
to declare SerialPortLib the "lowest level abstraction", and make the
affected lib instance self-contained.
In my RFC, we need to use gDS which is from
DxeServicesTableLib->EfiGetSystemConfigurationTable()->UefiLib, so that
we need to flatten EfiGetSystemConfigurationTable().
I think that's acceptable.
And
gDS->SetMemorySpaceAttributes() actually relies on
gEfiCpuArchProtocolGuid or it will return EFI_NOT_AVAILABLE_YET.
This is a valid dependency (even the PI spec spells it out). The way to
deal with it is to add gEfiCpuArchProtocolGuid to the DEPEX section of
the INF file -- this is possible for INF files of library instances as
well, but you have to be careful about module types. Please see the INF
spec on that.
Once you do this, modules linked against the lib instance will inherit
the lib instance's DEPEX, and "and it" together with the rest of their
DEPEX. IOW using the library will delay the containing driver module
until the CPU Arch protocol is available in the protocol database.
Yes, one is VariableRuntimeDxe, whose DEPEX is TRUE right now, but I think it
is acceptable.
I can take a try for the above proposal.
Thanks,
Heyi
Then the constructor can rely on the related DXE services.
Thanks
Laszlo
.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
