Re: [RFC 0/3] Enable runtime serial debug for ArmVirtQemu

[Laszlo Ersek <lersek@redhat.com>]

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