From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) by mx.groups.io with SMTP id smtpd.web10.484.1592589831856549362 for ; Fri, 19 Jun 2020 11:03:52 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=XiQ5ut2X; spf=pass (domain: apple.com, ip: 17.151.62.67, mailfrom: afish@apple.com) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 05JHfX4P054534; Fri, 19 Jun 2020 11:03:50 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=2lZQkRM3g3RYm/7nvyKSTaZx8Fd8yMOPvMvUq1SWt/g=; b=XiQ5ut2Xfu+Qng/BtPKiz7w8F0soLHUKctMEN47B8JfMytxG4HA+6MyBOZSdhKMpDEuz A5nS3RYG5j17K37ygox63BeVjhA4iRAtmMD7U61aUwi8l7n6LTriDBL3Z/sRIPuguAeM rmh/GmYyC4VWhpHg/yy5m5f2ilfUbpuJGYh+6P7sGqMwZ4Wy63gAuRjGrIjxHsRPQBj+ taiB96m8CLFyuRFaUV1XF8ykUwo29T8M+KEnPxhPTOgHn+DJ6OwmRd0XEFGpc2Tngkql vGg9iZNxkAO4Sn/aP749jDTigc1+3PHFUykNdF7nkbEaVpFebOh3/wdHTPdaTrnzROGH VA== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by nwk-aaemail-lapp02.apple.com with ESMTP id 31q661h48v-13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 19 Jun 2020 11:03:50 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QC600FVOQ6D0K40@rn-mailsvcp-mta-lapp04.rno.apple.com>; Fri, 19 Jun 2020 11:03:49 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QC600G00PU8DW00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Fri, 19 Jun 2020 11:03:49 -0700 (PDT) X-Va-A: X-Va-T-CD: e0acb9dc03d22e4581b62f3d752335f3 X-Va-E-CD: 4ef708a609e013abce501ddc1118d18f X-Va-R-CD: e4041007d070956f80549589e56c6c97 X-Va-CD: 0 X-Va-ID: 046c48a5-7ebe-4b07-951f-27b491412cf8 X-V-A: X-V-T-CD: e0acb9dc03d22e4581b62f3d752335f3 X-V-E-CD: 4ef708a609e013abce501ddc1118d18f X-V-R-CD: e4041007d070956f80549589e56c6c97 X-V-CD: 0 X-V-ID: 01a807b7-89ad-40c1-b059-3a9b004143ee X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216,18.0.687 definitions=2020-06-19_20:2020-06-19,2020-06-19 signatures=0 Received: from [17.235.27.98] (unknown [17.235.27.98]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QC6000LIQ6AOY00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Fri, 19 Jun 2020 11:03:48 -0700 (PDT) From: "Andrew Fish" Message-id: MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules Date: Fri, 19 Jun 2020 11:03:46 -0700 In-reply-to: Cc: "Bi, Dandan" , "rfc@edk2.groups.io" , "Dong, Eric" , "Ni, Ray" , "Wang, Jian J" , "Wu, Hao A" , "Tan, Ming" To: edk2-devel-groups-io , brian.johnson@hpe.com References: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216,18.0.687 definitions=2020-06-19_20:2020-06-19,2020-06-19 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_64F5FA03-CDD9-452B-B7D7-0D215FBA7E6A" --Apple-Mail=_64F5FA03-CDD9-452B-B7D7-0D215FBA7E6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 19, 2020, at 10:29 AM, Brian J. Johnson w= rote: >=20 > On 6/18/20 2:01 AM, Dandan Bi wrote: >> Hi All, >> >> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D2816 >> >> We plan to separate two kinds of NULL class libraries for Memory and se= rial handlers fromMdeModulePkg/Universal/StatusCodeHandler/=E2=80=A6/ Statu= sCodeHandlerPei/RuntimeDxe/Smm modules. >> The benefit we want to gain from this separation is to 1) make the code= clear and easy to maintain, 2) make platform flexible to choose any handle= r library they need, and it also can reduce image size since the unused han= dlers can be excluded. >> If you have any concern or comments for this separation, please let me = know. >> >> We plan to add new separated NULL class library MemoryStausCodeHandlerL= ib and SerialStatusCodeHandlerLib with different phase implementation into = MdeModulePkg\Library\ directory. >> The main tree structure may like below: >> MdeModulePkg\Library >> |------MemoryStausCodeHandlerLib >> |------|------ PeiMemoryStausCodeHandlerLib.inf >> |------|------ RuntimeDxeMemoryStatusCodeHandlerLib.inf >> |------|------ SmmMemoryStausCodeHandlerLib.inf >> |------SerialStatusCodeHandlerLib >> |------|------ PeiSerialStatusCodeHandlerLib.inf >> |------|------ RuntimeDxeSerialStatusCodeHandlerLib.inf >> |------|------ SmmSerialStatusCodeHandlerLib.inf >> >> >> We will update existing platform use cases in edk2 and edk2-platform re= po to cover the new NULL class library to make sure this change doesn=E2=80= = =99t impact any platform. >> After this separation, StatusCodeHandler module usage will like below, = and it=E2=80=99s also very flexible for platform to cover more handler libr= aries to meet their requirements. >> MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf { >> >> NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/PeiMemoryStausCodeH= andlerLib.inf >> NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/PeiSerialStatusCod= eHandlerLib.inf >> =E2=80=A6 >> } >> >> MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRu= ntimeDxe.inf { >> >> NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/RuntimeDxeMemorySta= usCodeHandlerLib.inf >> NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/RuntimeDxeSerialSt= atusCodeHandlerLib.inf >> =E2=80=A6 >> } >> >> MdeModulePkg/Universal/StatusCodeHandler/Smm/StatusCodeHandlerSmm.inf { >> >> NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/SmmMemoryStausC= odeHandlerLib.inf >> NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/SmmSerialStatusCod= eHandlerLib.inf >> =E2=80=A6 >> } >> >> >> Thanks, >> Dandan >=20 > Dandan, >=20 > We'll have a lot of layers of indirection.... The ReportStatusCodeRoute= r modules will call one or more StatusCodeHandlerModules, and the standard = StatusCodeHandler modules will call multiple StatusCodeHandlerLib libraries= . >=20 > How about adding StatusCodeHandlerLib support directly to the ReportStat= usCodeRouter modules? Then platforms could omit the StatusCodeHandler modu= les if they're only using the open-source code. That sounds like less over= head since fewer modules would be needed. >=20 >=20 I think the need to execute from ROM makes this tricky.=20 It looks to me that it is easy to move from PCD to libs for the StatusCode= Handler since registration is basically `RscHandlerPpi->Register (SerialSta= tusCodeReportWorker);`. The issue I see is the ReportStatusCodeRouter publi= shes RscHandlerPpi after the PEIMs constructor has been called and if the P= EIM. Given globals don=E2=80=99t work when running from ROM you would have = to do something like publish a HOB in the library constructor and then have= the GenericStatusCodePeiEntry() walk the HOBs and install the handlers. So= I guess it is a little easier than I 1st thought when I started writing th= is mail, but it would require a new public API.=20 Thanks, Andrew Fish > Thanks, >=20 > --=20 > Brian J. Johnson > Enterprise X86 Lab >=20 > Hewlett Packard Enterprise >=20 > hpe.com >=20 --Apple-Mail=_64F5FA03-CDD9-452B-B7D7-0D215FBA7E6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jun 19, 2= 020, at 10:29 AM, Brian J. Johnson <brian.johnson@hpe.com> wrote:

On 6/18/20 2:01 AM, Dandan Bi wrote:
Hi All,
 
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D2816<= /a>
=  
We plan to separate two kinds= of NULL class libraries for Memory and serial handlers fromM= deModulePkg/Universal/StatusCodeHandler/=E2=80=A6/ StatusCodeHandlerPei/Run= timeDxe/Smm modules.<= o:p class=3D"">
The benefit we want = to gain from this separation is to 1) make the code clear and easy to maint= ain, 2) make platform flexible to choose any handler library they need, and= it also can reduce image size since the unused handlers can be excluded.
If you have any conce= rn or comments for this separation, please let me know.
 
We plan to add new separated NULL class library MemoryStausCode= HandlerLib and SerialStatusCodeH= andlerLib with differ= ent phase implementation into MdeModulePkg\Library\ directory.
The main tree structure may like below:
MdeModulePkg\Library
|------MemoryStausCodeHandler= Lib
|------|----= -- PeiMemoryStausCodeHandlerLib.inf
|------|------ RuntimeDxeMemoryStatusCodeHandlerLib.inf<= o:p class=3D"">
|------|------ SmmMe= moryStausCodeHandlerLib.inf
|------SerialStatusCodeHandlerLib=
|------|------ PeiSerialStatusCodeH= andlerLib.inf
|-----= -|------ RuntimeDxeSerialStatusCodeHandlerLib.inf
|------|------ SmmSerialStatusCodeHandlerLib.= inf
 
 
We wil= l update existing platform use cases in edk2 and edk2-platform repo to cove= r the new NULL class library to make sure this change doesn=E2=80=99t impac= t any platform.
Afte= r this separation, StatusCodeHandler module usage will like below, and it= =E2=80=99s also very flexible for platform to cover more handler libraries= to meet their requirements.
MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.= inf {
  <LibraryClasses>
NULL|Md= eModulePkg/Library/MemoryStausCodeHandlerLib/PeiMemoryStausCodeHandlerLib.i= nf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/PeiSerialStatus= CodeHandlerLib.inf
&= nbsp;   =E2=80= =A6
}
 
MdeModulePkg/Universal/StatusCodeHandler/Runti= meDxe/StatusCodeHandlerRuntimeDxe.inf  {
  = ;<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHa= ndlerLib/RuntimeDxeMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library= /SerialStatusCodeHandlerLib/RuntimeDxeSerialStatusCodeHandlerLib.inf
    =E2=80=A6<= /div>
}
 
MdeModulePkg/Universal/StatusCodeHandler/Smm/StatusCodeHandlerSmm.inf {
  <LibraryClasses><= /o:p>
    NULL|MdeModulePkg= /Library/MemoryStausCodeHandlerLib/SmmMemoryStausCodeHandlerLib.inf
NULL|M= deModulePkg/Library/SerialStatusCodeHandlerLib/SmmSerialStatusCodeHandlerLi= b.inf
  &n= bsp; =E2=80=A6
}
 
 
Thanks,
Danda= n


Dandan,=

We'll have a lot of layers of ind= irection....  The ReportStatusCodeRouter modules will call one or more= StatusCodeHandlerModules, and the standard StatusCodeHandler modules will = call multiple StatusCodeHandlerLib libraries.

How about adding StatusCodeHandlerLib support directly to the R= eportStatusCodeRouter modules?  Then platforms could omit the StatusCo= deHandler modules if they're only using the open-source code.  That so= unds like less overhead since fewer modules would be needed.



I = think the need to execute from ROM makes this tricky. 




--Apple-Mail=_64F5FA03-CDD9-452B-B7D7-0D215FBA7E6A--