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

[Heyi Guo <guoheyi@huawei.com>]

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