Re: 回复: [edk2-devel] A proposal to reduce incompatible case

[Laszlo Ersek]

On 11/20/20 10:02, Ard Biesheuvel wrote:
> On 11/20/20 8:27 AM, gaoliming wrote:
>> Zhiguang:
>>    This proposal can reduce the potential library class dependency.
>> Each package has its xxxPkgLib.dsc.inc file that includes the library
>> instances from this package.
>>    Platform DSC can include the required package lib.dsc.inc file for
>> the library instances. Can you work out the code changes to
>> demonstrate this idea?
>>
> 
> +1 for this idea. This would allow us to remove a *lot* of boilerplate
> in the .DSC files, and focus on the libraries that actually matter for
> the platform at hand.

I feel like I'm in *cautious* agreement with this idea.

In particular, I'd *only* like those lib class -> lib instance
resolutions to be extracted, to DSC include files, that *cannot* involve
platform choice. To put it differently, single-instance lib classes.

("Single-instance" can be interpreted per module type / per architecture
of course -- so if a lib class has exactly 1 instance for PEIMs and
exactly 1 (different) instance for DXE_DRIVERs, then those resolutions
qualify for extraction.)

If a library class genuinely has multiple instances in core edk2, then
extracting a "default" resolution would be *wrong*, in my opinion. Every
platform needs to make the choice explicitly, in such cases. This
applies even if a lib class only has two instances, a functional one,
and a Null one. The functional one should not be assumed default.

Example: extracting the UefiLib resolution is valid. Extracting a
SerialPortLib class resolution is invalid.

Basically, I'd like to avoid *overrides*. Overrides are terribly hard to
reason about.

... If someone wants to work on this, they'll have to implement this
with *super small* patches, where every patch extracts resolutions for
just one lib class. I would reject any patch that required me to review
the extraction of two or more lib classes, from an OVMF or ArmVirt DSC
file, at the same time.

There is big potential in this proposal for making platform DSC files
*permanently* more difficult to understand & analyze. I don't
immediately see this proposal as a good solution for avoiding the
current kind of platform DSC breakage. Platform CI would be much better,
in my opinion. The proposal does seem workable, but the implementation
needs to be surgical, IMO.

OK, I'll get off my soap box now.

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#67765): https://edk2.groups.io/g/devel/message/67765
Mute This Topic: https://groups.io/mt/78384573/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-