From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.byosoft.com.cn (mail.byosoft.com.cn [58.240.74.242]) by mx.groups.io with SMTP id smtpd.web08.1701.1652491007000278687 for ; Fri, 13 May 2022 18:16:48 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=none, err=permanent DNS error (domain: byosoft.com.cn, ip: 58.240.74.242, mailfrom: gaoliming@byosoft.com.cn) Received: from DESKTOPS6D0PVI ([101.224.116.119]) (envelope-sender ) by 192.168.6.13 with ESMTP for ; Sat, 14 May 2022 09:16:26 +0800 X-WM-Sender: gaoliming@byosoft.com.cn X-Originating-IP: 101.224.116.119 X-WM-AuthFlag: YES X-WM-AuthUser: gaoliming@byosoft.com.cn From: "gaoliming" To: "'Michael Kubacki'" , , "'Ard Biesheuvel'" Cc: "'Abner Chang'" , "'Andrew Fish'" , "'Anthony Perard'" , "'Ard Biesheuvel'" , "'Benjamin You'" , "'Brijesh Singh'" , "'Erdem Aktas'" , "'Gerd Hoffmann'" , "'Guo Dong'" , "'Hao A Wu'" , "'James Bottomley'" , "'Jian J Wang'" , "'Jiewen Yao'" , "'Jordan Justen'" , "'Julien Grall'" , "'Leif Lindholm'" , "'Maurice Ma'" , "'Min Xu'" , "'Nickle Wang'" , "'Peter Grehan'" , "'Ray Ni'" , "'Rebecca Cran'" , "'Sami Mujawar'" , "'Sean Rhodes'" , "'Sebastien Boeuf'" , "'Tom Lendacky'" References: <20220426012918.1216-1-mikuback@linux.microsoft.com> <00d401d8601f$3981cc10$ac856430$@byosoft.com.cn> <5e04954f-271e-b7b5-cd58-456310c4030b@linux.microsoft.com> <0337311a-fb5c-55bf-c415-6a178f293943@linux.microsoft.com> <30a3487e-2a6b-5bc5-7db7-626c9b44fe32@linux.microsoft.com> In-Reply-To: <30a3487e-2a6b-5bc5-7db7-626c9b44fe32@linux.microsoft.com> Subject: =?UTF-8?B?5Zue5aSNOiDlm57lpI06IFtlZGsyLWRldmVsXSBbUEFUQ0ggdjUgMC84XSBBZGQgVmFyaWFibGUgRmxhc2ggSW5mbyBIT0I=?= Date: Sat, 14 May 2022 09:16:25 +0800 Message-ID: <00a701d86730$3bb999a0$b32ccce0$@byosoft.com.cn> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI0Yy49haEnV8mscETCKlnDeBIkewJk2TNWAXn9Ob8Bn5wwQwGcLhmRATI8D60BrZ5Fo6wVxK5w Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: zh-cn Michael: This is my suggestion to resolve such compatible issue. As you say, it ne= eds more review and discussion. So, it may not be applied immediately.=20 If this patch set needs to catch this table tag, it has to take current w= ay to update each DSC file. Have the patch set got reviewed-by from Package= maintainers? If yes, I think this patch set can still be merged for this s= table tag.=20 Thanks Liming > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Michael Kubacki > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2022=E5=B9=B45=E6=9C=8814=E6=97=A5 = 2:24 > =E6=94=B6=E4=BB=B6=E4=BA=BA: gaoliming ; devel@= edk2.groups.io; 'Ard > Biesheuvel' > =E6=8A=84=E9=80=81: 'Abner Chang' ; 'Andrew Fish' > ; 'Anthony Perard' ; 'Ard > Biesheuvel' ; 'Benjamin You' > ; 'Brijesh Singh' ; 'Erdem > Aktas' ; 'Gerd Hoffmann' ; > 'Guo Dong' ; 'Hao A Wu' ; > 'James Bottomley' ; 'Jian J Wang' > ; 'Jiewen Yao' ; 'Jordan > Justen' ; 'Julien Grall' ; 'Le= if > Lindholm' ; 'Maurice Ma' > ; 'Min Xu' ; 'Nickle Wang' > ; 'Peter Grehan' ; 'Ray Ni' > ; 'Rebecca Cran' ; 'Sami Mujawar' > ; 'Sean Rhodes' ; > 'Sebastien Boeuf' ; 'Tom Lendacky' > > =E4=B8=BB=E9=A2=98: Re: =E5=9B=9E=E5=A4=8D: [edk2-devel] [PATCH v5 0/8] A= dd Variable Flash Info HOB >=20 > Can you please respond with your preference? >=20 > I am ready to do this but if it is required now, it should be documented > so it becomes a consistent pattern for future changes. >=20 > Thanks, > Michael >=20 > On 5/10/2022 11:01 AM, Michael Kubacki wrote: > > What's the plan for next steps? The v5 PR has been up for two weeks wit= h > > no changes. > > > > Are we going to try to define a long-term pattern for how to include ne= w > > library classes in core packages or merge the patch series? > > > > Thanks, > > Michael > > > > On 5/5/2022 9:52 PM, Michael Kubacki wrote: > >> I still believe a long term design pattern deserves more focus and > >> documentation than a quick modification to this series. > >> > >> Can you confirm that you envision MdePkg/MdeLibs.dsc.inc serving as a > >> monolithic host of various other default library class instances? > >> > >> That somewhat inverts the package relationships, the code reviewer > >> policy would need to clarify when the original package owners are > >> included on the MdePkg patch (to confirm they agree with the default > >> instance choice), and "core" packages would have to be clearly defined > >> in this context for developers to know what packages are allowed. > >> > >> In addition, this does not mean there still won't be some level of > >> platform integration thrash. For example, if a new library class > >> instance added to MdePkg/MdeLibs.dsc.inc requires another library > >> class (or multiple others), those might not be added to the DSC > >> include file. They could have been satisfied in the original package > >> DSC (or a test platform DSC) but that doesn't mean they will be in all > >> platform DSC files. So when the MdeLibs.dsc.inc file update occurs, > >> those platforms break and need to add the library class that was > >> already specified in other DSC files. > >> > >> So I request that if this is the preferred approach, that it be agreed > >> upon (e.g. dedicated RFC), documented, and consistently followed by > >> other contributions as well. > >> > >> Regards, > >> Michael > >> > >> On 5/4/2022 9:27 PM, gaoliming wrote: > >>> Michael: > >>> I would suggest to reuse MdePkg/MdeLibs.dsc.inc to list the > >>> library and PCD from the edk2 core packages, such as MdePkg, > >>> MdeModulePkg, CryptoPkg, SecurirtyPkg and so on. Those packages are > >>> required by every platforms. They can't be separated. So, I think > >>> MdePkg/MdeLibs.dsc.inc is for edk2 core packages, not only for MdePkg= . > >>> > >>> Thanks > >>> Liming > >>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > >>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: devel@edk2.groups.io =E4=BB=A3=E8=A1=A8 > Michael > >>>> Kubacki > >>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2022=E5=B9=B44=E6=9C=8829=E6= =97=A5 23:48 > >>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Ard Biesheuvel > >>>> =E6=8A=84=E9=80=81: edk2-devel-groups-io ; Abn= er Chang > >>>> ; Andrew Fish ; Anthony > Perard > >>>> ; Ard Biesheuvel > >>>> ; > >>>> Benjamin You ; Brijesh Singh > >>>> ; Erdem Aktas ; > Gerd > >>>> Hoffmann ; Guo Dong ; Hao > A > >>>> Wu ; James Bottomley ; > Jian J > >>>> Wang ; Jiewen Yao ; > Jordan > >>>> Justen ; Julien Grall ; L= eif > >>>> Lindholm ; Liming Gao > >>>> ; Maurice Ma ; > Min Xu > >>>> ; Nickle Wang ; Peter > Grehan > >>>> ; Ray Ni ; Rebecca Cran > >>>> ; Sami Mujawar ; > Sean > >>>> Rhodes ; Sebastien Boeuf > >>>> ; Tom Lendacky > > >>>> =E4=B8=BB=E9=A2=98: Re: [edk2-devel] [PATCH v5 0/8] Add Variable Fla= sh Info HOB > >>>> > >>>> I agree that would be a useful tool and in the case of changes such = as > >>>> this that provide backward compatibility with existing functionality= , > >>>> particularly helpful. > >>>> > >>>> Some packages such as MdePkg > >>>> > (https://github.com/tianocore/edk2/blob/master/MdePkg/MdeLibs.dsc.inc) > >>>> and NetworkPkg > >>>> > (https://github.com/tianocore/edk2/blob/master/NetworkPkg/NetworkCom > >>>> ponents.dsc.inc) > >>>> provide DSC files that a platform can override if necessary. > >>>> > >>>> However, this does not exist for all edk2 packages. I did not introd= uce > >>>> such a file in MdeModulePkg because I believe that is an independent > >>>> package design decision outside the scope of this series and, if tha= t > >>>> change was made, it should include libraries other than just this > >>>> instance. That would lead to additional churn and a larger platform > >>>> integration debate, important to that topic, but separate from the > >>>> current state this contribution is based against. > >>>> > >>>> While includes be helpful, it can encourage platform owners to ignor= e > >>>> potential creep in functionality they should be aware of. > >>>> > >>>> For example, the DSC update is mostly being given to platforms to fi= x > >>>> their immediate build problem. But, a platform owner might also choo= se > >>>> to update their FVB driver to use this interface to get flash > >>>> information as opposed to directly using PCDs as many do today. > >>>> That's a > >>>> decision they need to evaluate and make but they should be aware of > the > >>>> interface and make that decision. By directly reviewing/integrating = the > >>>> change for their platform, they are more explicitly made aware of th= is > >>>> new interface to form that decision. > >>>> > >>>> Also, when many include files get involved, platform build complexit= y > >>>> and developer frustration can increase due to nesting and order of > >>>> include files. Values (library classes, PCDs, etc.) can be overridde= n > >>>> more than once. Ultimately, this is technically manageable by utiliz= ing > >>>> build reports and understanding the EDK II build output in more deta= il. > >>>> > >>>> Again, I think this conversation is useful but requires much more ti= me > >>>> to address questions such as the following: > >>>> > >>>> 1. Should a different mechanism for default library classes be > >>>> introduced? > >>>> > >>>> 2. Should all packages in edk2 provide such an include file? If so, > >>>> does > >>>> it only provide the DSC file (like MdePkg) or other files (like > >>>> NetworkPkg which includes FDF)? > >>>> > >>>> 3. Which library classes for a given package should be given default > >>>> instances? > >>>> > >>>> 4. How would each platform package maintainer like to maintain their > >>>> platform build? > >>>> > >>>> Example: Would MinPlatformPkg prefer to keep its own "core" include > >>>> files > >>>> > (https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/M= i > >>>> > >>>> nPlatformPkg/Include) > >>>> or reconcile them with include files (possibly introducing an > >>>> additional > >>>> layer of nesting)? Would others prefer not to use includes at all to > >>>> keep a flat, simpler file? > >>>> > >>>> How would someone updating the platform code due to an edk2 change > be > >>>> aware of this per-platform policy? > >>>> > >>>> To my understanding, the answers to these today are: > >>>> > >>>> 1. No > >>>> 2. No / decided on per-change basis > >>>> 3. Unknown > >>>> 4. Unknown > >>>> > >>>> (2) adds friction to the edk2 contribution process as expectation is > >>>> unclear. > >>>> > >>>> (3) adds churn into the platform integration process as the integrat= ion > >>>> process for existing code is subject to change over time (e.g. reali= ze > >>>> library class is now in DSC and remove from platform DSC to use incl= ude > >>>> instance). > >>>> > >>>> (4) adds friction to the edk2 contribution process as expectation is > >>>> unclear. Also, somewhat error prone. There's also a level of due > >>>> diligence needed to confirm if a platform that already has an > >>>> include is > >>>> overriding that in another DSC file. If so, is that still the correc= t > >>>> behavior or should it be modified. > >>>> > >>>> Regards, > >>>> Michael > >>>> > >>>> On 4/29/2022 9:45 AM, Ard Biesheuvel wrote: > >>>>> On Tue, 26 Apr 2022 at 03:29, > wrote: > >>>>>> > >>>>>> From: Michael Kubacki > >>>>>> > >>>>>> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3D3479 > >>>>>> > >>>>>> Platforms: This series introduces a new library class called > >>>>>> VariableFlashInfoLib. Platforms using the variable modules will > >>>>>> need to specify these library classes. See the patches at the > >>>>>> end of this series for examples of the change needed in the > >>>>>> platform DSC file. I have attempted to update all open-source > >>>>>> platforms in edk2 and edk2-platforms in this series and > >>>>>> https://edk2.groups.io/g/devel/message/89148. > >>>>>> > >>>>> > >>>>> I will make the same remark here as I made in response to the > >>>>> edk2-platforms series: > >>>>> > >>>>> Could we please consider introducing a way to define the default > >>>>> resolution of a library class? That way, all this churn and > >>>>> unnecessary breakage would not be necessary, as defining a resoluti= on > >>>>> would only be necessary when deviating from the default. In fact, w= e > >>>>> might be able to clean up some .DSCs considerably by defining defau= lts > >>>>> for library classes that only have one (or very few) implementation= s. > >>>>> > >>>>> > >>>>>> The UEFI variable drivers such as VariableRuntimeDxe, VariableSmm, > >>>>>> VariableStandaloneMm, etc. (and their dependent protocol/library > >>>>>> stack), typically acquire UEFI variable store flash information > >>>>>> with PCDs declared in MdeModulePkg. > >>>>>> > >>>>>> For example: > >>>>>> [Pcd] > >>>>>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariabl > eBase > >>>>>> > >>>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64 > >>>>>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariabl > eSize > >>>>>> > >>>>>> These PCDs work as-is in the StandaloneMm driver if they are not > >>>>>> dynamic such as Dynamic or DynamicEx because PCD services are not > >>>>>> readily available in the Standalone MM environment. Platforms that > >>>>>> use Standalone MM today, must define these PCDs as FixedAtBuild in > >>>>>> their platform build. However, the PCDs do allow platforms to trea= t > >>>>>> the PCDs as Dynamic/DynamicEx and being able to support that is > >>>>>> currently a gap for Standalone MM. > >>>>>> > >>>>>> This patch series introduces a HOB that can be produced by the > >>>>>> platform to provide the same information. The HOB list is > >>>>>> available to Standalone MM. > >>>>>> > >>>>>> The PCD declarations are left as-is in MdeModulePkg for backward > >>>>>> compatibility. This means unless a platform wants to use the HOB, > >>>>>> their code will continue to work with no change (they do not need > >>>>>> to produce the HOB). Only if the HOB is found, is its value used > >>>>>> instead of the PCDs. > >>>>>> > >>>>>> Due to the large number of consumers of this information, access > >>>>>> to the base address and size values is abstracted in a new library > >>>>>> class (as requested in the v1 series) called VariableFlashInfoLib. > >>>>>> > >>>>>> The API of VariableFlashInfoLib does not bind the underlying data > >>>>>> structure to the information returned to library users to allow > >>>>>> flexibility in the library implementation in the future. > >>>>>> > >>>>>> V5 changes. > >>>>>> 1. Made GetVariableFlashInfoFromHob() in > BaseVariableFlashInfoLib.c > >>>>>> STATIC. > >>>>>> 2. Added a section in commit v5 [3/8] to explicitly state that the > >>>>>> commit introduces a dependency that requires a change in > >>>>>> platform > >>>>>> build. Please see patches v5 [5/8] - v5 [8/8] for examples o= f > >>>>>> how to integrate this change (add VariableFlashInfoLib librar= y > >>>>>> to DSC file). > >>>>>> > >>>>>> V4 changes: > >>>>>> 1. Add a UINT32 "Reserved" field to VARIABLE_FLASH_INFO. > >>>>>> 2. Add a descriptive comment to VariableFlashInfo.h to explain > >>>>>> HOB usage. > >>>>>> > >>>>>> V3 changes: > >>>>>> 1. To better clarify usage, renamed the members > >>>>>> "NvStorageBaseAddress" and "NvStorageLength" in > >>>>>> "VARIABLE_FLASH_INFO" to "NvVariableBaseAddress" and > >>>>>> "NvVariableLength". > >>>>>> 2. Added description comments to the fields in > "VARIABLE_FLASH_INFO". > >>>>>> > >>>>>> V2 changes: > >>>>>> 1. Abstracted flash info data access with VariableFlashInfoLib. > >>>>>> 2. Updated package builds in the repo that build the variable and > >>>>>> FTW drivers to include VariableFlashInfoLib. > >>>>>> 3. Removed a redundant variable assignment in VariableSmm.c. > >>>>>> 4. Updated comments in FtwMisc.c and FaultTolerantWritePei.c to > >>>>>> indicate driver assumption is UINTN (not UINT32) > >>>>>> 5. Added a version field to the VARIABLE_FLASH_INFO structure. > >>>>>> > >>>>>> Cc: Abner Chang > >>>>>> Cc: Andrew Fish > >>>>>> Cc: Anthony Perard > >>>>>> Cc: Ard Biesheuvel > >>>>>> Cc: Benjamin You > >>>>>> Cc: Brijesh Singh > >>>>>> Cc: Erdem Aktas > >>>>>> Cc: Gerd Hoffmann > >>>>>> Cc: Guo Dong > >>>>>> Cc: Hao A Wu > >>>>>> Cc: James Bottomley > >>>>>> Cc: Jian J Wang > >>>>>> Cc: Jiewen Yao > >>>>>> Cc: Jordan Justen > >>>>>> Cc: Julien Grall > >>>>>> Cc: Leif Lindholm > >>>>>> Cc: Liming Gao > >>>>>> Cc: Maurice Ma > >>>>>> Cc: Min Xu > >>>>>> Cc: Nickle Wang > >>>>>> Cc: Peter Grehan > >>>>>> Cc: Ray Ni > >>>>>> Cc: Rebecca Cran > >>>>>> Cc: Sami Mujawar > >>>>>> Cc: Sean Rhodes > >>>>>> Cc: Sebastien Boeuf > >>>>>> Cc: Tom Lendacky > >>>>>> Signed-off-by: Michael Kubacki > >>>>>> > >>>>>> Michael Kubacki (8): > >>>>>> MdeModulePkg: Add Variable Flash Info HOB > >>>>>> MdeModulePkg/VariableFlashInfoLib: Add initial library > >>>>>> MdeModulePkg/Variable: Consume Variable Flash Info > >>>>>> MdeModulePkg/FaultTolerantWrite: Consume Variable Flash > Info > >>>>>> ArmVirtPkg/ArmVirt.dsc.inc: Add VariableFlashInfoLib > >>>>>> EmulatorPkg: Add VariableFlashInfoLib > >>>>>> OvmfPkg: Add VariableFlashInfoLib > >>>>>> UefiPayloadPkg: Add VariableFlashInfoLib > >>>>>> > >>>>>> > >>>> > MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.c > >>>> > >>>> | 179 ++++++++++++++++++++ > >>>>>> MdeModulePkg/Universal/FaultTolerantWriteDxe/FtwMisc.c > >>>> | 41 +++-- > >>>>>> > >>>> > MdeModulePkg/Universal/FaultTolerantWriteDxe/UpdateWorkingBlock.c > >>>> | 7 +- > >>>>>> > >>>> > MdeModulePkg/Universal/FaultTolerantWritePei/FaultTolerantWritePei.c > >>>> | 28 +-- > >>>>>> MdeModulePkg/Universal/Variable/Pei/Variable.c > >>>> | 14 +- > >>>>>> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c > >>>> | 16 +- > >>>>>> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableNonVo > latile.c > >>>> | 14 +- > >>>>>> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c > >>>> | 17 +- > >>>>>> ArmVirtPkg/ArmVirt.dsc.inc > >>>> | 1 + > >>>>>> EmulatorPkg/EmulatorPkg.dsc > >>>> | 1 + > >>>>>> MdeModulePkg/Include/Guid/VariableFlashInfo.h > >>>> | 111 ++++++++++++ > >>>>>> MdeModulePkg/Include/Library/VariableFlashInfoLib.h > >>>> | 68 ++++++++ > >>>>>> > >>>> > MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.i > >>>> > >>>> nf | 48 ++++++ > >>>>>> > >>>> > MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.u > >>>> > >>>> ni | 12 ++ > >>>>>> MdeModulePkg/MdeModulePkg.dec > >>>> | 8 + > >>>>>> MdeModulePkg/MdeModulePkg.dsc > >>>> | 2 + > >>>>>> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerant > Write.h > >>>> | 7 +- > >>>>>> > >>>> > MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf > >>>> | 10 +- > >>>>>> > >>>> > MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf > >>>> | 10 +- > >>>>>> > >>>> > MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal > >>>> oneMm.inf | 10 +- > >>>>>> > >>>> > MdeModulePkg/Universal/FaultTolerantWritePei/FaultTolerantWritePei.inf > >>>> | 10 +- > >>>>>> MdeModulePkg/Universal/Variable/Pei/Variable.h > >>>> | 2 + > >>>>>> MdeModulePkg/Universal/Variable/Pei/VariablePei.inf > >>>> | 5 +- > >>>>>> MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h > >>>> | 7 +- > >>>>>> > >>>> > MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf > >>>> | 5 +- > >>>>>> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.i > nf > >>>> | 5 +- > >>>>>> > >>>> > MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf > >>>> | 5 +- > >>>>>> OvmfPkg/AmdSev/AmdSevX64.dsc > >>>> | 1 + > >>>>>> OvmfPkg/Bhyve/BhyveX64.dsc > >>>> | 1 + > >>>>>> OvmfPkg/CloudHv/CloudHvX64.dsc > >>>> | 1 + > >>>>>> OvmfPkg/IntelTdx/IntelTdxX64.dsc > >>>> | 1 + > >>>>>> OvmfPkg/Microvm/MicrovmX64.dsc > >>>> | 1 + > >>>>>> OvmfPkg/OvmfPkgIa32.dsc > >>>> | 1 + > >>>>>> OvmfPkg/OvmfPkgIa32X64.dsc > >>>> | 1 + > >>>>>> OvmfPkg/OvmfPkgX64.dsc > >>>> | 1 + > >>>>>> OvmfPkg/OvmfXen.dsc > >>>> | 1 + > >>>>>> UefiPayloadPkg/UefiPayloadPkg.dsc > >>>> | 1 + > >>>>>> 37 files changed, 559 insertions(+), 94 deletions(-) > >>>>>> create mode 100644 > >>>> > MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.c > >>>> > >>>>>> create mode 100644 > MdeModulePkg/Include/Guid/VariableFlashInfo.h > >>>>>> create mode 100644 > >>>> MdeModulePkg/Include/Library/VariableFlashInfoLib.h > >>>>>> create mode 100644 > >>>> > MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.i > >>>> > >>>> nf > >>>>>> create mode 100644 > >>>> > MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.u > >>>> > >>>> ni > >>>>>> > >>>>>> -- > >>>>>> 2.28.0.windows.1 > >>>>>> > >>>> > >>>> > >>>>=20 > >>>> > >>> > >>>