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. 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
