<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="ProgId" content="Word.Document"> <meta name="Generator" content="Microsoft Word 15"> <meta name="Originator" content="Microsoft Word 15"> <link rel="File-List" href="cid:filelist.xml@01D6C717.C88EB820"><style></style> </head> <body lang="EN-US" link="#0563C1" vlink="#954F72" style="tab-interval:.5in"> <div class="WordSection1"> Hi Zhiguang,<o:p></o:p> <o:p> </o:p> I do not think generating these lists of lib mapping only from evaluation of the edk2 and edk2-platforms DSC usage is correct.<o:p></o:p> <o:p> </o:p> The only way to know for sure that there is a default mapping is if the design and implementation of the library class intended only a single mapping.<o:p></o:p> This would have to be documented in the lib class and the lib instance.<o:p></o:p> <o:p> </o:p> An example where this will have the incorrect behavior is a platform specific library class where a only a template of that lib class is provided<o:p></o:p> as a *Null instance. The expectation is that a platform that needs this feature would be required to provide their own instance of that <o:p></o:p> library class in their platform DSC. There may be features that are not used by the platforms in edk2-platforms. In that case your <o:p></o:p> tool would identify the *Null instance as the only one. All platforms would build, but would not have the expected behavior. It <o:p></o:p> would be better for platforms to break at build time with a missing library mapping in this case.<o:p></o:p> <o:p> </o:p> There are a few categories of libraries<o:p></o:p> <ol style="margin-top:0in" start="1" type="1"> <li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">*Null library instances that are a template for a platform specific lib. Also used for package verification builds. <o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">Library class where different library instances are expected to be used in a single platform.<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">Library class with a single lib instance and all platforms are expected to use that one library instance.<o:p></o:p></li></ol> <o:p> </o:p> I like the idea that packages providing a DSC INC file with default mappings/settings, but we need to make sure it is always correct<o:p></o:p> and should only be applied to category (3). This may require manual analysis in each package or extra information added to<o:p></o:p> lib class/lib instance.<o:p></o:p> <o:p> </o:p> Thanks,<o:p></o:p> <o:p> </o:p> Mike<o:p></o:p> <o:p> </o:p> <div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> From: Liu, Zhiguang <zhiguang.liu@intel.com> Sent: Sunday, November 29, 2020 4:32 AM To: Laszlo Ersek <lersek@redhat.com>; Ard Biesheuvel <ard.biesheuvel@arm.com>; gaoliming <gaoliming@byosoft.com.cn>; devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Feng, Bob C <bob.c.feng@intel.com>; Tian, Hot <hot.tian@intel.com>; 'Bret Barkelew' <bret@corthon.com> Cc: Bi, Dandan <dandan.bi@intel.com>; 'Chao Zhang' <chao.b.zhang@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; 'Liming Gao' <liming.gao@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>; 'Andrew Fish' <afish@apple.com>; Ni, Ray <ray.ni@intel.com>; 'Bret Barkelew' <brbarkel@microsoft.com>; Kinney, Michael D <michael.d.kinney@intel.com>; debtech@gmail.com; awarkentin@vmware.com; michael.kubacki@outlook.com Subject: RE: 回复: [edk2-devel] A proposal to reduce incompatible case<o:p></o:p> </div> </div> <o:p> </o:p> Hi all,<o:p></o:p> <o:p> </o:p> I write a python script to do the work, including classify all the library instance, generating the including lib file.<o:p></o:p> In the attachment file, the first sheet includes all "Single-instance", which means in edk2 and edk2-platforms repo, only one inf files has the specified library name.<o:p></o:p> The second sheet includes all "Multi-Single-instance", which means in edk2 and edk2-platforms repo, for a specified module type and arch, this inf is a "Single-instance". <o:p></o:p> I think the library instance in the first two sheet can be extracted as a XXXLibs.dsc.inc<o:p></o:p> <o:p> </o:p> Here is the draft code <o:p></o:p> <a href="https://github.com/LiuZhiguang001/edk2/commits/extract_lib">https://github.com/LiuZhiguang001/edk2/commits/extract_lib</a><o:p></o:p> <o:p> </o:p> Here is the source code of this tool<o:p></o:p> <a href="https://github.com/LiuZhiguang001/MyTool/tree/extract_lib">https://github.com/LiuZhiguang001/MyTool/tree/extract_lib</a><o:p></o:p> <o:p> </o:p> Please review the excel and the draft code.<o:p></o:p> If no comments, I will send out a formal patch next week.<o:p></o:p> <o:p> </o:p> Thanks<o:p></o:p> Zhiguang<o:p></o:p> <o:p> </o:p> > -----Original Message-----<o:p></o:p> > From: Liu, Zhiguang<o:p></o:p> > Sent: Saturday, November 21, 2020 2:08 PM<o:p></o:p> > To: Laszlo Ersek <<a href="mailto:lersek@redhat.com">lersek@redhat.com</a>>; Ard Biesheuvel<o:p></o:p> > <<a href="mailto:ard.biesheuvel@arm.com">ard.biesheuvel@arm.com</a>>; gaoliming <<a href="mailto:gaoliming@byosoft.com.cn">gaoliming@byosoft.com.cn</a>>;<o:p></o:p> > <a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a>; Yao, Jiewen <<a href="mailto:jiewen.yao@intel.com">jiewen.yao@intel.com</a>>; Feng, Bob C<o:p></o:p> > <<a href="mailto:bob.c.feng@intel.com">bob.c.feng@intel.com</a>>; Tian, Hot <<a href="mailto:hot.tian@intel.com">hot.tian@intel.com</a>>; 'Bret Barkelew'<o:p></o:p> > <<a href="mailto:bret@corthon.com">bret@corthon.com</a>><o:p></o:p> > Cc: Bi, Dandan <<a href="mailto:dandan.bi@intel.com">dandan.bi@intel.com</a>>; 'Chao Zhang'<o:p></o:p> > <<a href="mailto:chao.b.zhang@intel.com">chao.b.zhang@intel.com</a>>; Wang, Jian J <<a href="mailto:jian.j.wang@intel.com">jian.j.wang@intel.com</a>>; Wu, Hao A<o:p></o:p> > <<a href="mailto:hao.a.wu@intel.com">hao.a.wu@intel.com</a>>; 'Liming Gao' <<a href="mailto:liming.gao@intel.com">liming.gao@intel.com</a>>; Justen, Jordan L<o:p></o:p> > <<a href="mailto:jordan.l.justen@intel.com">jordan.l.justen@intel.com</a>>; 'Andrew Fish' <<a href="mailto:afish@apple.com">afish@apple.com</a>>; Ni, Ray<o:p></o:p> > <<a href="mailto:ray.ni@intel.com">ray.ni@intel.com</a>>; 'Bret Barkelew' <<a href="mailto:brbarkel@microsoft.com">brbarkel@microsoft.com</a>>; Kinney,<o:p></o:p> > Michael D <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>>; <a href="mailto:debtech@gmail.com">debtech@gmail.com</a>;<o:p></o:p> > <a href="mailto:awarkentin@vmware.com">awarkentin@vmware.com</a>; <a href="mailto:michael.kubacki@outlook.com">michael.kubacki@outlook.com</a><o:p></o:p> > Subject: RE: 回复: [edk2-devel] A proposal to reduce incompatible case<o:p></o:p> > <o:p></o:p> > Hi all,<o:p></o:p> > Thanks all for the comments.<o:p></o:p> > <o:p></o:p> > Hi Jiewen:<o:p></o:p> > I think we are thinking from the different aspects.<o:p></o:p> > I want the XXPkgLib.dsc.inc to specify the default library instance that the<o:p></o:p> > package will consumes.<o:p></o:p> > You may want it to specify the default library instance that the package will<o:p></o:p> > produce.<o:p></o:p> > I now think your way makes more sense, and also align with the implement in<o:p></o:p> > NetworkPkg.<o:p></o:p> > I will follow your way when working on the demo code.<o:p></o:p> > <o:p></o:p> > Hi Bret:<o:p></o:p> > I see you point about that platform should be like platform and should only<o:p></o:p> > change in the stable tag.<o:p></o:p> > I partly agree with you, but in fact there are some projects need to keep the<o:p></o:p> > Edk2 updated frequently.<o:p></o:p> > And my proposal should also be an optional way to add the library instance.<o:p></o:p> > Platform dsc can also choose the original way. I think it is at least harmless if<o:p></o:p> > some platforms choose not to use this way.<o:p></o:p> > <o:p></o:p> > Hi Lazlo:<o:p></o:p> > I agree with you that this proposal should only extract "Single-instance".<o:p></o:p> > After all, this proposal is meant to reduce incompatible case like this<o:p></o:p> > VaribalePolicyLib.<o:p></o:p> > I want to the platform to be "Seamless update" in such case.<o:p></o:p> > However, if this lib has two instances, it is a platform's choice and platform<o:p></o:p> > owner should be aware the change.<o:p></o:p> > Therefore, "Single-instance" and "Multiple-instance" should be totally different<o:p></o:p> > case, and we should only enable this proposal to "Single-instance".<o:p></o:p> > <o:p></o:p> > Hi Liming and Ard,<o:p></o:p> > Thanks for liking this idea.<o:p></o:p> > I plan to work on the demo code next week and send it here for more<o:p></o:p> > comments.<o:p></o:p> > <o:p></o:p> > BTW, about the file name, I want to it to follow the existing rule of NetworkPkg<o:p></o:p> > and ArmVirtPkg.<o:p></o:p> > I think for MdeModulePkg, "MdeModuleLibs.dsc.inc" will be better.<o:p></o:p> > <o:p></o:p> > Thanks<o:p></o:p> > Zhiguang<o:p></o:p> > <o:p></o:p> > > -----Original Message-----<o:p></o:p> > > From: Laszlo Ersek <<a href="mailto:lersek@redhat.com">lersek@redhat.com</a>><o:p></o:p> > > Sent: Friday, November 20, 2020 7:18 PM<o:p></o:p> > > To: Ard Biesheuvel <<a href="mailto:ard.biesheuvel@arm.com">ard.biesheuvel@arm.com</a>>; gaoliming<o:p></o:p> > > <<a href="mailto:gaoliming@byosoft.com.cn">gaoliming@byosoft.com.cn</a>>; <a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a>; Yao, Jiewen<o:p></o:p> > > <<a href="mailto:jiewen.yao@intel.com">jiewen.yao@intel.com</a>>; Liu, Zhiguang <<a href="mailto:zhiguang.liu@intel.com">zhiguang.liu@intel.com</a>>;<o:p></o:p> > > <a href="mailto:michael.kubacki@outlook.com">michael.kubacki@outlook.com</a>; <a href="mailto:awarkentin@vmware.com">awarkentin@vmware.com</a>;<o:p></o:p> > <a href="mailto:debtech@gmail.com">debtech@gmail.com</a>;<o:p></o:p> > > Feng, Bob C <<a href="mailto:bob.c.feng@intel.com">bob.c.feng@intel.com</a>>; Tian, Hot <<a href="mailto:hot.tian@intel.com">hot.tian@intel.com</a>><o:p></o:p> > > Cc: 'Bret Barkelew' <<a href="mailto:bret@corthon.com">bret@corthon.com</a>>; Bi, Dandan<o:p></o:p> > > <<a href="mailto:dandan.bi@intel.com">dandan.bi@intel.com</a>>; 'Chao Zhang' <<a href="mailto:chao.b.zhang@intel.com">chao.b.zhang@intel.com</a>>; Wang,<o:p></o:p> > > Jian J <<a href="mailto:jian.j.wang@intel.com">jian.j.wang@intel.com</a>>; Wu, Hao A <<a href="mailto:hao.a.wu@intel.com">hao.a.wu@intel.com</a>>;<o:p></o:p> > > 'Liming Gao' <<a href="mailto:liming.gao@intel.com">liming.gao@intel.com</a>>; Justen, Jordan L<o:p></o:p> > > <<a href="mailto:jordan.l.justen@intel.com">jordan.l.justen@intel.com</a>>; 'Andrew Fish' <<a href="mailto:afish@apple.com">afish@apple.com</a>>; Ni, Ray<o:p></o:p> > > <<a href="mailto:ray.ni@intel.com">ray.ni@intel.com</a>>; 'Bret Barkelew' <<a href="mailto:brbarkel@microsoft.com">brbarkel@microsoft.com</a>>; Kinney,<o:p></o:p> > > Michael D <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>><o:p></o:p> > > Subject: Re: 回复: [edk2-devel] A proposal to reduce incompatible case<o:p></o:p> > ><o:p></o:p> > > On 11/20/20 10:02, Ard Biesheuvel wrote:<o:p></o:p> > > > On 11/20/20 8:27 AM, gaoliming wrote:<o:p></o:p> > > >> Zhiguang:<o:p></o:p> > > >> This proposal can reduce the potential library class dependency.<o:p></o:p> > > >> Each package has its xxxPkgLib.dsc.inc file that includes the<o:p></o:p> > > >> library instances from this package.<o:p></o:p> > > >> Platform DSC can include the required package lib.dsc.inc file<o:p></o:p> > > >> for the library instances. Can you work out the code changes to<o:p></o:p> > > >> demonstrate this idea?<o:p></o:p> > > >><o:p></o:p> > > ><o:p></o:p> > > > +1 for this idea. This would allow us to remove a *lot* of<o:p></o:p> > > > +boilerplate<o:p></o:p> > > > in the .DSC files, and focus on the libraries that actually matter<o:p></o:p> > > > for the platform at hand.<o:p></o:p> > ><o:p></o:p> > > I feel like I'm in *cautious* agreement with this idea.<o:p></o:p> > ><o:p></o:p> > > In particular, I'd *only* like those lib class -> lib instance<o:p></o:p> > > resolutions to be extracted, to DSC include files, that *cannot*<o:p></o:p> > > involve platform choice. To put it differently, single-instance lib classes.<o:p></o:p> > ><o:p></o:p> > > ("Single-instance" can be interpreted per module type / per<o:p></o:p> > > architecture of course -- so if a lib class has exactly 1 instance for<o:p></o:p> > > PEIMs and exactly 1<o:p></o:p> > > (different) instance for DXE_DRIVERs, then those resolutions qualify<o:p></o:p> > > for<o:p></o:p> > > extraction.)<o:p></o:p> > ><o:p></o:p> > > If a library class genuinely has multiple instances in core edk2, then<o:p></o:p> > > extracting a "default" resolution would be *wrong*, in my opinion.<o:p></o:p> > > Every platform needs to make the choice explicitly, in such cases.<o:p></o:p> > > This applies even if a lib class only has two instances, a functional<o:p></o:p> > > one, and a Null one. The functional one should not be assumed default.<o:p></o:p> > ><o:p></o:p> > > Example: extracting the UefiLib resolution is valid. Extracting a<o:p></o:p> > > SerialPortLib class resolution is invalid.<o:p></o:p> > ><o:p></o:p> > > Basically, I'd like to avoid *overrides*. Overrides are terribly hard<o:p></o:p> > > to reason about.<o:p></o:p> > ><o:p></o:p> > > ... If someone wants to work on this, they'll have to implement this<o:p></o:p> > > with *super<o:p></o:p> > > small* patches, where every patch extracts resolutions for just one<o:p></o:p> > > lib class. I would reject any patch that required me to review the<o:p></o:p> > > extraction of two or more lib classes, from an OVMF or ArmVirt DSC file, at<o:p></o:p> > the same time.<o:p></o:p> > ><o:p></o:p> > > There is big potential in this proposal for making platform DSC files<o:p></o:p> > > *permanently* more difficult to understand & analyze. I don't<o:p></o:p> > > immediately see this proposal as a good solution for avoiding the<o:p></o:p> > > current kind of platform DSC breakage. Platform CI would be much<o:p></o:p> > > better, in my opinion. The proposal does seem workable, but the<o:p></o:p> > implementation needs to be surgical, IMO.<o:p></o:p> > ><o:p></o:p> > > OK, I'll get off my soap box now.<o:p></o:p> > ><o:p></o:p> > > Thanks<o:p></o:p> > > Laszlo<o:p></o:p> <o:p> </o:p> </div> </div> </body> </html> <div width="1" style="color:white;clear:both">_._,_._,_</div> <hr> Groups.io Links: You receive all messages sent to this group. <a target="_blank" href="https://edk2.groups.io/g/devel/message/68094">View/Reply Online (#68094)</a> | | <a target="_blank" href="https://groups.io/mt/78384573/1813853">Mute This Topic</a> | <a href="https://edk2.groups.io/g/devel/post">New Topic</a> <a href="https://edk2.groups.io/g/devel/editsub/1813853">Your Subscription</a> | <a href="mailto:devel+owner@edk2.groups.io">Contact Group Owner</a> | <a href="https://edk2.groups.io/g/devel/unsub">Unsubscribe</a> [edk2-devel-archive@redhat.com] <div width="1" style="color:white;clear:both">_._,_._,_</div>