[AMD Official Use Only - General]

 

Don’t remove it for sure if there is already some use cases. Hah RedfishPkg, I forget this. 😊

 

 

From: Kinney, Michael D <michael.d.kinney@intel.com>
Sent: Wednesday, October 12, 2022 9:09 AM
To: Chang, Abner <Abner.Chang@amd.com>; Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; quic_llindhol@quicinc.com; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com>; Sunil V L <sunilvl@ventanamicro.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: lichao <lichao@loongson.cn>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com>; Grimes, Paul <Paul.Grimes@amd.com>; He, Jiangang <Jiangang.He@amd.com>; Andrew Fish <afish@apple.com>
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for archs

 

Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.

 

There are many instances of both in edk2 repo.  I would not remove from spec.

 

NetworkPkg/SnpDxe/Get_status.c

NetworkPkg/SnpDxe/Mcast_ip_to_mac.c

NetworkPkg/SnpDxe/Receive_filters.c

NetworkPkg/SnpDxe/Station_address.c

OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h

OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_32.h

OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_64.h

OvmfPkg/Include/IndustryStandard/Xen/event_channel.h

OvmfPkg/Include/IndustryStandard/Xen/grant_table.h

OvmfPkg/Include/IndustryStandard/Xen/hvm/hvm_op.h

OvmfPkg/Include/IndustryStandard/Xen/io/xs_wire.h

OvmfPkg/PlatformCI/iasl_ext_dep.yaml

RedfishPkg/Library/JsonLib/jansson_config.h

RedfishPkg/Library/JsonLib/jansson_private_config.h

 

Mike

 

From: Chang, Abner <Abner.Chang@amd.com>
Sent: Tuesday, October 11, 2022 5:52 PM
To: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; quic_llindhol@quicinc.com; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com>; Sunil V L <sunilvl@ventanamicro.com>
Cc: lichao <lichao@loongson.cn>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com>; Grimes, Paul <Paul.Grimes@amd.com>; He, Jiangang <Jiangang.He@amd.com>; Andrew Fish <afish@apple.com>
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for archs

 

[AMD Official Use Only - General]

 

I was thinking to remove ‘_’ from edkII coding standard if there is no use case or rare people like it appears in file/dir name.

 

Abner

 

From: Kinney, Michael D <michael.d.kinney@intel.com>
Sent: Wednesday, October 12, 2022 4:16 AM
To: Chang, Abner <Abner.Chang@amd.com>; Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; quic_llindhol@quicinc.com; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com>; Sunil V L <sunilvl@ventanamicro.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: lichao <lichao@loongson.cn>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com>; Grimes, Paul <Paul.Grimes@amd.com>; He, Jiangang <Jiangang.He@amd.com>; Andrew Fish <afish@apple.com>
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for archs

 

[AMD Official Use Only - General]

 

Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.

 

I do not have a strong opinion either way. 

 

Some searching indicates there is some debate between use of spaces, underscores, and dashes in filenames.

 

The filename/dirname requirements for EDK II allow ‘_’ and ‘-‘ as long as they are not the first or last character.  Spaces ‘ ‘ are not allowed.

 

[A-Za-z][_A-Za-z0-9-]*[A-Za-z0-9]+

 

Mike

 

From: Chang, Abner <Abner.Chang@amd.com>
Sent: Monday, October 10, 2022 7:21 PM
To: Ni, Ray <ray.ni@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io; quic_llindhol@quicinc.com; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com>; Sunil V L <sunilvl@ventanamicro.com>
Cc: lichao <lichao@loongson.cn>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com>; Grimes, Paul <Paul.Grimes@amd.com>; He, Jiangang <Jiangang.He@amd.com>; Andrew Fish <afish@apple.com>
Subject: Re: [edk2-devel] The principles of EDK2 module reconstruction for archs

 

[AMD Official Use Only - General]

 

Removing '_' seems make the folder hard to read, but not too bad to me though. I am fine with removing '_'. 

Leif and Mike, how do you think?

 

Ex:

Riscv64Ia32X64 compares Riscv64_Ia32_X64.

ArmAArch64 compares to Arm_AArch64.

 

Abner

From: Ni, Ray <ray.ni@intel.com>
Sent: Tuesday, October 11, 2022 9:51:24 AM
To: Chang, Abner <Abner.Chang@amd.com>; Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io <devel@edk2.groups.io>; quic_llindhol@quicinc.com <quic_llindhol@quicinc.com>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com>; Sunil V L <sunilvl@ventanamicro.com>
Cc: lichao <lichao@loongson.cn>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com>; Grimes, Paul <Paul.Grimes@amd.com>; He, Jiangang <Jiangang.He@amd.com>; Andrew Fish <afish@apple.com>
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for archs

 

Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.


Abner, Mike, Leif,
"Ia32_X64" is the first case in edk2 that underscore "_" is used as part of file path.
Shall we use "Ia32X64" (removing "_")?

I know that Sunil is following the guideline.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F94912%3Fp%3D%252C%252C%252C20%252C0%252C0%252C0%253A%253Arecentpostdate%252Fsticky%252C%252CUefiCpuPkg%252FCpuTimerLib%252C20%252C2%252C0%252C94233015&amp;data=05%7C01%7CAbner.Chang%40amd.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=5wOiTArZyySLos4A%2FQHOC3gryUIZ8K4SgNxeTwfANMY%3D&amp;reserved=0

Thanks,
Ray

> -----Original Message-----
> From: Chang, Abner <Abner.Chang@amd.com>
> Sent: Thursday, October 6, 2022 4:37 PM
> To: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io;
> quic_llindhol@quicinc.com; Ni, Ray <ray.ni@intel.com>; Attar, AbdulLateef
> (Abdul Lateef) <AbdulLateef.Attar@amd.com>; Sunil V L
> <sunilvl@ventanamicro.com>
> Cc: lichao <lichao@loongson.cn>; Kirkendall, Garrett
> <Garrett.Kirkendall@amd.com>; Grimes, Paul <Paul.Grimes@amd.com>; He,
> Jiangang <Jiangang.He@amd.com>; Andrew Fish <afish@apple.com>
> Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for
> archs
>
> [AMD Official Use Only - General]
>
> Here is the update of the Wiki page for the consistency with edk2 C Coding
> Standard Spec.
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchangab%2Ftianocore.github.io%2Fwiki%2FThe-Guidelines-of-&amp;data=05%7C01%7CAbner.Chang%40amd.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=i5RSe41cuzD48VB32KeG0M3Vp7T%2FEqe3ncKNfGCjfIU%3D&amp;reserved=0
> Reconstruct-EDK-II-Modules-for-Processor-Architectures-and-Vendors'-
> Implementation
>
> Thanks
> Abner
>
> > -----Original Message-----
> > From: Chang, Abner
> > Sent: Wednesday, October 5, 2022 1:39 PM
> > To: Kinney, Michael D <michael.d.kinney@intel.com>;
> devel@edk2.groups.io;
> > quic_llindhol@quicinc.com; Ni, Ray <ray.ni@intel.com>; Attar, AbdulLateef
> > (Abdul Lateef) <AbdulLateef.Attar@amd.com>; Sunil V L
> > <sunilvl@ventanamicro.com>
> > Cc: lichao <lichao@loongson.cn>; Kirkendall, Garrett
> > <Garrett.Kirkendall@amd.com>; Grimes, Paul <Paul.Grimes@amd.com>;
> He,
> > Jiangang <Jiangang.He@amd.com>; Andrew Fish <afish@apple.com>
> > Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for
> > archs
> >
> > [AMD Official Use Only - General]
> >
> > PR updated
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore-docs%2Fedk2-&amp;data=05%7C01%7CAbner.Chang%40amd.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=YDYXODgrQhuLlP8DTsLr%2F4ct2JH3aw8y2SPg8tk5fgg%3D&amp;reserved=0
> > CCodingStandardsSpecification/pull/2/commits. Please check it.
> >
> > Thanks
> > Abner
> >
> > > -----Original Message-----
> > > From: Kinney, Michael D <michael.d.kinney@intel.com>
> > > Sent: Tuesday, October 4, 2022 10:18 PM
> > > To: Chang, Abner <Abner.Chang@amd.com>; devel@edk2.groups.io;
> > > quic_llindhol@quicinc.com; Ni, Ray <ray.ni@intel.com>; Attar,
> > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com>; Sunil V L
> > > <sunilvl@ventanamicro.com>; Kinney, Michael D
> > > <michael.d.kinney@intel.com>
> > > Cc: lichao <lichao@loongson.cn>; Kirkendall, Garrett
> > > <Garrett.Kirkendall@amd.com>; Grimes, Paul <Paul.Grimes@amd.com>;
> > He,
> > > Jiangang <Jiangang.He@amd.com>; Andrew Fish <afish@apple.com>
> > > Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction
> > > for archs
> > >
> > > Caution: This message originated from an External Source. Use proper
> > > caution when opening attachments, clicking links, or responding.
> > >
> > >
> > > I would not add link to Wiki from EDK II C Coding Standard Specification.
> > >
> > > We want documents published from tianocore-docs to support
> standalone
> > > formats such as PDF and if there is a link in one of those documents,
> > > we want to know that it is a permanent link.  I am concerned we may
> > > reorganize Wiki pages and links in PDF would become stale.
> > >
> > > Links from Wiki to specs makes sense.
> > >
> > > Mike
> > >
> > > > -----Original Message-----
> > > > From: Chang, Abner <Abner.Chang@amd.com>
> > > > Sent: Tuesday, October 4, 2022 7:05 AM
> > > > To: Kinney, Michael D <michael.d.kinney@intel.com>;
> > > > devel@edk2.groups.io; quic_llindhol@quicinc.com; Ni, Ray
> > > > <ray.ni@intel.com>; Attar, AbdulLateef (Abdul Lateef)
> > > > <AbdulLateef.Attar@amd.com>; Sunil V L <sunilvl@ventanamicro.com>
> > > > Cc: lichao <lichao@loongson.cn>; Kirkendall, Garrett
> > > > <Garrett.Kirkendall@amd.com>; Grimes, Paul
> <Paul.Grimes@amd.com>;
> > > > He, Jiangang <Jiangang.He@amd.com>; Andrew Fish
> <afish@apple.com>
> > > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > > reconstruction for archs
> > > >
> > > > [AMD Official Use Only - General]
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Kinney, Michael D <michael.d.kinney@intel.com>
> > > > > Sent: Tuesday, October 4, 2022 12:54 AM
> > > > > To: devel@edk2.groups.io; Chang, Abner <Abner.Chang@amd.com>;
> > > > > quic_llindhol@quicinc.com; Ni, Ray <ray.ni@intel.com>; Attar,
> > > > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com>; Sunil V L
> > > > > <sunilvl@ventanamicro.com>; Kinney, Michael D
> > > > > <michael.d.kinney@intel.com>
> > > > > Cc: lichao <lichao@loongson.cn>; Kirkendall, Garrett
> > > > > <Garrett.Kirkendall@amd.com>; Grimes, Paul
> > <Paul.Grimes@amd.com>;
> > > > > He, Jiangang <Jiangang.He@amd.com>; Andrew Fish
> > <afish@apple.com>
> > > > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > > > reconstruction for archs
> > > > >
> > > > > Caution: This message originated from an External Source. Use
> > > > > proper caution when opening attachments, clicking links, or
> responding.
> > > > >
> > > > >
> > > > > Hi Abner,
> > > > >
> > > > > responses below.
> > > > >
> > > > > Mike
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> > > > > > Chang, Abner via groups.io
> > > > > > Sent: Sunday, October 2, 2022 10:37 PM
> > > > > > To: Kinney, Michael D <michael.d.kinney@intel.com>;
> > > > > > devel@edk2.groups.io; quic_llindhol@quicinc.com; Ni, Ray
> > > > > > <ray.ni@intel.com>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > <AbdulLateef.Attar@amd.com>; Sunil V L
> > > > > > <sunilvl@ventanamicro.com>
> > > > > > Cc: lichao <lichao@loongson.cn>; Kirkendall, Garrett
> > > > > > <Garrett.Kirkendall@amd.com>; Grimes, Paul
> > > > > > <Paul.Grimes@amd.com>;
> > > > > He,
> > > > > > Jiangang <Jiangang.He@amd.com>; Andrew Fish <afish@apple.com>
> > > > > > Subject: Re: [edk2-devel] The principles of EDK2 module
> > > > > > reconstruction for archs
> > > > > >
> > > > > > [AMD Official Use Only - General]
> > > > > >
> > > > > > Mike,
> > > > > > Agree. This can be mentioned on the Wiki page. Also, this would
> > > > > > require the discussion between maintainer and contributor. I
> > > > > > would say
> > > > > maintainer has the responsibility to make sure an arch folder is
> > > > > only created when necessary.
> > > > >
> > > > > Agreed
> > > > Ok, I will update Directory and file names section.
> > > > >
> > > > > >
> > > > > > Do you agree with the arch concatenate solution for arch folder?
> > > > > > That
> > > > > means IA32_X64 instead of X86 (I am fine with this)?
> > > > >
> > > > > Yes
> > > > >
> > > > > > However, there is one scenario. Assume there were two arch
> > > > > > folders
> > > > > > IA32_X64 and RISCV64. Then ARM shares the code with IA32_X64,
> we
> > > > > > may
> > > > > rename IA32_X64 to IA32_X64_ARM.
> > > > > > Although the directory naming is not real a problem to the
> > > > > > build, a separate ARM folder seems easier? Or we can just allow
> > > > > > this kind of folder
> > > > > naming structure, however we let maintainer to make the decision?
> > > > >
> > > > > I would let the maintainer make the decision.  For your example,
> > > > > another approach may be to move the IA32_X64 content up a level so
> > > > > it is common and is used by IA32, X64, ARM.  And leave RISCV64
> > > > > folder for an arch that has special requirements.  I think having
> > > > > some flexibility in the guidelines is very beneficial.  The main
> > > > > goal is for consistency when a specific guideline is followed.
> > > > I think we can have the naming rules in the edk2 C coding standard
> > > > spec and
> > > put these guidelines on the Wiki page.
> > > > Is that ok to have a link to Wiki page in the edk2 C coding standard spec?
> > > >
> > > > Abner
> > > >
> > > > >
> > > > > >
> > > > > > Abner
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Kinney, Michael D <michael.d.kinney@intel.com>
> > > > > > > Sent: Monday, October 3, 2022 1:18 PM
> > > > > > > To: Chang, Abner <Abner.Chang@amd.com>;
> > devel@edk2.groups.io;
> > > > > > > quic_llindhol@quicinc.com; Ni, Ray <ray.ni@intel.com>; Attar,
> > > > > > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com>; Sunil
> > > > > > > V L <sunilvl@ventanamicro.com>; Kinney, Michael D
> > > > > > > <michael.d.kinney@intel.com>
> > > > > > > Cc: lichao <lichao@loongson.cn>; Kirkendall, Garrett
> > > > > > > <Garrett.Kirkendall@amd.com>; Grimes, Paul
> > > > > > > <Paul.Grimes@amd.com>; He, Jiangang
> <Jiangang.He@amd.com>;
> > > > > > > Andrew Fish <afish@apple.com>
> > > > > > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > > > > > reconstruction for archs
> > > > > > >
> > > > > > > Caution: This message originated from an External Source. Use
> > > > > > > proper caution when opening attachments, clicking links, or
> > responding.
> > > > > > >
> > > > > > >
> > > > > > > Abner,
> > > > > > >
> > > > > > > I think another guideline is to minimize the number of
> > subdirectories.
> > > > > > >
> > > > > > > Only create them if it helps with the organization and long
> > > > > > > term maintenance of the component.
> > > > > > >
> > > > > > > Mike
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Chang, Abner <Abner.Chang@amd.com>
> > > > > > > > Sent: Sunday, October 2, 2022 8:13 PM
> > > > > > > > To: Kinney, Michael D <michael.d.kinney@intel.com>;
> > > > > > > > devel@edk2.groups.io; quic_llindhol@quicinc.com; Ni, Ray
> > > > > > > > <ray.ni@intel.com>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > <AbdulLateef.Attar@amd.com>; Sunil V L
> > > > > > > > <sunilvl@ventanamicro.com>
> > > > > > > > Cc: lichao <lichao@loongson.cn>; Kirkendall, Garrett
> > > > > > > > <Garrett.Kirkendall@amd.com>; Grimes, Paul
> > > > > <Paul.Grimes@amd.com>;
> > > > > > > He,
> > > > > > > > Jiangang <Jiangang.He@amd.com>; Andrew Fish
> > > > > > > > <afish@apple.com>
> > > > > > > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > > > > > > reconstruction for archs
> > > > > > > >
> > > > > > > > [AMD Official Use Only - General]
> > > > > > > >
> > > > > > > > Hi Mike and Leif,
> > > > > > > > First of all, we don't use arch folder if the module is
> > > > > > > > mainly for a specific arch in obviously. So we will  have
> > > > > > > > both common and arch-specific
> > > > > > > files constructed under module/library root.
> > > > > > > >
> > > > > > >
> > > > >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > > ed
> > > > > > > k
> > > > > > > 2
> > > > > > >
> > > > >
> > >
> > > .groups.io%2Fg%2Fdevel%2Fmessage%2F94567&amp;data=05%7C01%7C
> A
> > > > > > > bner.Chan
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> g%40amd.com%7Cd49cbbe6d3d942bd69a308daa4fea41b%7C3dd8961fe4884
> > > > > > > e608e11a
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 82d994e183d%7C0%7C0%7C638003710850252776%7CUnknown%7CTWFpbGZ
> > > > > > > sb3d8eyJWI
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> > > > > > > 000%7
> > > > > > > >
> > > > > > >
> > > > >
> >
> C%7C%7C&amp;sdata=eiLOC0G9WZWKqm2ALcAiKr7SPBP5AgDdAxogHlv5pI
> > > > > > > M%3D&amp;r
> > > > > > > > eserved=0
> > > > > > > > SmmCpuFeatureLib\Ia32
> > > > > > > > SmmCpuFeatureLib\X64
> > > > > > > > SmmCpuFeatureLib\SmmCpuFeatureLib.c
> > > > > > > > SmmCpuFeatureLib\SmmCpuFeatureLibCommon.c
> > > > > > > > SmmCpuFeatureLib\IntelSmmCPuFeaturesLib
> > > > > > > > SmmCpuFeatureLib\AmdlSmmCPuFeaturesLib
> > > > > > > >
> > > > > > > >
> > > > > > > > > > Could we concatenate architectures?
> > > > > > > > > > I.e. AARCH64_ARM, IA32_X64, AARCH64_RISCV64... ?
> > > > > > > > Looks like below?
> > > > > > > >
> > > > > > > > CpuDxe\IA32_X64\IA32\abc.nasm
> > CpuDxe\IA32_X64\X64\abc.nasm
> > > > > > > > CpuDxe\IA32_X64\CpuDxe.c CpuDxe\IA32_X64\AmdCpuDxe.c
> > > > > > > > CpuDxe\IA32_X64\IntelCpuDxe.c CpuDxe\RiscV64\CpuDxe.c
> > > > > > > > CpuDxe\ARM\CpuDxe.c CpuDxe\
> > > > > > > >                CpuDxeCommon.c  // If required.
> > > > > > > >                 CpuDxe.inf               // Use INF section arch modifier for
> X86,
> > > > > RISC-V
> > > > > > > and ARM.
> > > > > > > >                 CpuDxeAmd.inf        // Separate INF for AMD.
> > > > > > > >
> > > > > > > > Seems ok, but is AARCH64_RISCV64 a real case?  Or it means
> > > > > > > > we can create a folder "AARCH64_RISCV64" when there are
> some
> > > > > > > > common
> > > > > files
> > > > > > > shared by AARCH64 and RISCV64?
> > > > > > > >
> > > > > > > > For the 32/64 bit support, it can still stay under module
> > > > > > > > root and don't need to assign a folder for them unless the
> > > > > > > > arch has the different
> > > > > > > implementation.
> > > > > > > > Regards,
> > > > > > > > Abner
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Kinney, Michael D <michael.d.kinney@intel.com>
> > > > > > > > > Sent: Saturday, October 1, 2022 2:52 AM
> > > > > > > > > To: devel@edk2.groups.io; quic_llindhol@quicinc.com;
> > > > > > > > > Chang, Abner <Abner.Chang@amd.com>; Ni, Ray
> > > > > > > > > <ray.ni@intel.com>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > <AbdulLateef.Attar@amd.com>; Sunil V L
> > > > > > > > > <sunilvl@ventanamicro.com>; Kinney, Michael D
> > > > > > > > > <michael.d.kinney@intel.com>
> > > > > > > > > Cc: lichao <lichao@loongson.cn>; Kirkendall, Garrett
> > > > > > > > > <Garrett.Kirkendall@amd.com>; Grimes, Paul
> > > > > > > > > <Paul.Grimes@amd.com>; He, Jiangang
> > <Jiangang.He@amd.com>;
> > > > > > > > > Andrew Fish <afish@apple.com>
> > > > > > > > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > > > > > > > reconstruction for archs
> > > > > > > > >
> > > > > > > > > Caution: This message originated from an External Source.
> > > > > > > > > Use proper caution when opening attachments, clicking
> > > > > > > > > links, or
> > > > > responding.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Hi Leif,
> > > > > > > > >
> > > > > > > > > Concatenation is a good idea.  Makes it more obvious and
> > > > > > > > > can be easily adopted for new CPU archs.
> > > > > > > > >
> > > > > > > > > There is an additional case where an implementation does
> > > > > > > > > not have differences based on CPU Arch or Vendor, but it
> > > > > > > > > does have differences based on the bit- width of the CPU.
> > > > > > > > > Take BaseSafeIntLib as
> > > > > > > an example.
> > > > > > > > > It has source files for 32-bit CPUs, 64-bit CPUs, and CPU
> > > > > > > > > arch specific file for Ebc because Ebc adapts to 32-bit or
> > > > > > > > > 64-bit depending on the CPU type the EBC Interpreter is
> running.
> > > > > > > > >
> > > > > > > > > MdePkg/Library/BaseSafeIntLib/
> > > > > > > > >   BaseSafeIntLib.inf
> > > > > > > > >   SafeIntLib.c
> > > > > > > > >   SafeIntLib32.c
> > > > > > > > >   SafeIntLib64.c
> > > > > > > > >   SafeIntLibEbc.c
> > > > > > > > >
> > > > > > > > > Should we add "32" and "64" as supported suffices in file
> names?
> > > > > > > > >
> > > > > > > > > If we wanted to put type content into a subdirectory, what
> > > > > > > > > would be the suggested directory name for "32" and "64".
> > > > > > > > > Or do we want to require this type of difference to always
> > > > > > > > > be files in top level directory of
> > > > > > > the modules/library?
> > > > > > > > >
> > > > > > > > > Best regards,
> > > > > > > > >
> > > > > > > > > Mike
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: devel@edk2.groups.io <devel@edk2.groups.io> On
> > > > > > > > > > Behalf Of Leif Lindholm
> > > > > > > > > > Sent: Friday, September 30, 2022 9:09 AM
> > > > > > > > > > To: devel@edk2.groups.io; Kinney, Michael D
> > > > > > > > > > <michael.d.kinney@intel.com>; Chang, Abner
> > > > > > > <Abner.Chang@amd.com>;
> > > > > > > > > > Ni, Ray <ray.ni@intel.com>; Attar, AbdulLateef (Abdul
> > > > > > > > > > Lateef) <AbdulLateef.Attar@amd.com>; Sunil V L
> > > > > > > > > > <sunilvl@ventanamicro.com>
> > > > > > > > > > Cc: lichao <lichao@loongson.cn>; Kirkendall, Garrett
> > > > > > > > > > <Garrett.Kirkendall@amd.com>; Grimes, Paul
> > > > > > > <Paul.Grimes@amd.com>;
> > > > > > > > > > He, Jiangang <Jiangang.He@amd.com>; Andrew Fish
> > > > > > > <afish@apple.com>
> > > > > > > > > > Subject: Re: [edk2-devel] The principles of EDK2 module
> > > > > > > > > > reconstruction for archs
> > > > > > > > > >
> > > > > > > > > > I agree similar things will certainly happen for
> > > > > > > > > > ARM/AARCH64, which will probably be noticeable when I
> > > > > > > > > > start eradicating ArmPkg and putting the arch-standard
> > > > > > > > > > bits into
> > > (mostly) MdePkg.
> > > > > > > > > >
> > > > > > > > > > But I like the ability to see already at the filesystem
> > > > > > > > > > level which files belong to the architecture I'm
> > > > > > > > > > currently working on and
> > > > > > > which don't.
> > > > > > > > > >
> > > > > > > > > > Could we concatenate architectures?
> > > > > > > > > > I.e. AARCH64_ARM, IA32_X64, AARCH64_RISCV64... ?
> > > > > > > > > >
> > > > > > > > > > /
> > > > > > > > > >      Leif
> > > > > > > > > >
> > > > > > > > > > On 2022-09-30 08:28, Michael D Kinney wrote:
> > > > > > > > > > > Hi Abner,
> > > > > > > > > > >
> > > > > > > > > > > One comment is on adding a new CPU type dir name of
> 'X86'
> > > > > > > > > > > for content that is common for IA32/X64.
> > > > > > > > > > >
> > > > > > > > > > > I can imagine a similar case for ARM/AARCH64 and for
> > > > > > > > > > > the RISCV (32, 64, 128) cases.
> > > > > > > > > > >
> > > > > > > > > > > I think I would prefer to drop X86 and if there are
> > > > > > > > > > > files that are common to multiple CPU architectures
> > > > > > > > > > > then they are considered common and are in top
> > > > > > > > > > > directory of module and the file header and INF file
> > > > > > > > > > > can clearly document which CPU archs the file
> > > > > > > applies.
> > > > > > > > > > >
> > > > > > > > > > > Mike
> > > > > > > > > > >
> > > > > > > > > > >> -----Original Message-----
> > > > > > > > > > >> From: Chang, Abner <Abner.Chang@amd.com>
> > > > > > > > > > >> Sent: Friday, September 30, 2022 12:11 AM
> > > > > > > > > > >> To: Ni, Ray <ray.ni@intel.com>; Attar, AbdulLateef
> > > > > > > > > > >> (Abdul
> > > > > > > > > > >> Lateef) <AbdulLateef.Attar@amd.com>; Sunil V L
> > > > > > > > > > >> <sunilvl@ventanamicro.com>; devel@edk2.groups.io;
> > > > > > > > > > >> Kinney, Michael D <michael.d.kinney@intel.com>
> > > > > > > > > > >> Cc: lichao <lichao@loongson.cn>; Kirkendall, Garrett
> > > > > > > > > > >> <Garrett.Kirkendall@amd.com>; Grimes, Paul
> > > > > > > > > > >> <Paul.Grimes@amd.com>; He, Jiangang
> > > > > <Jiangang.He@amd.com>;
> > > > > > > Leif
> > > > > > > > > > >> Lindholm <quic_llindhol@quicinc.com>; Andrew Fish
> > > > > > > > > > >> <afish@apple.com>
> > > > > > > > > > >> Subject: RE: [edk2-devel] The principles of EDK2
> > > > > > > > > > >> module reconstruction for archs
> > > > > > > > > > >>
> > > > > > > > > > >> [AMD Official Use Only - General]
> > > > > > > > > > >>
> > > > > > > > > > >> Thanks Ray, here are my responses.
> > > > > > > > > > >> https://nam11.safelinks.protection.outlook.com/?url=h
> > > > > > > > > > >> tt
> > > > > > > > > > >> ps%3
> > > > > > > > > > >> A%2F
> > > > > > > > > > >> %2Fg
> > > > > > > > > > >> ithub.com%2Ftianocore-docs%2Fedk2-
> > > > > > > CCodingStandardsSpecification
> > > > > > > > > > >> %2Fp
> > > > > > > > > > >>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> ull%2F2&amp;data=05%7C01%7CAbner.Chang%40amd.com%7C7c3292c8bd2
> > > > > > > f4
> > > > > > > > > 86f
> > > > > > > > > > >>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 920908daa314e8e6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6
> > > > > > > > > 3800
> > > > > > > > > > >>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 1607445876768%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> > > > > > > JQ
> > > > > > > > > IjoiV
> > > > > > > > > > >>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata
> > > > > > > =
> > > > > > > > > HAq
> > > > > > > > > > >>
> > > > > > >
> > > > >
> > ou4JyY1yxDthuQ1dEKcF7Q3o4W77Oo9rOOvkXNWU%3D&amp;reserved=0
> > > > > > > > > > >>
> > > > > > > > > > >> @Kinney, Michael D we may also need your
> > > > > > > > > > >> clarification on the
> > > > > > > comments.
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >>> -----Original Message-----
> > > > > > > > > > >>> From: Ni, Ray <ray.ni@intel.com>
> > > > > > > > > > >>> Sent: Thursday, September 29, 2022 3:42 PM
> > > > > > > > > > >>> To: Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > > >>> <AbdulLateef.Attar@amd.com>; Chang, Abner
> > > > > > > > > > >>> <Abner.Chang@amd.com>; Sunil V L
> > > > > > > > > > >>> <sunilvl@ventanamicro.com>; devel@edk2.groups.io
> > > > > > > > > > >>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>;
> > > > > > > > > > >>> lichao <lichao@loongson.cn>; Kirkendall, Garrett
> > > > > > > > > > >>> <Garrett.Kirkendall@amd.com>; Grimes, Paul
> > > > > > > > > > >>> <Paul.Grimes@amd.com>; He, Jiangang
> > > > > <Jiangang.He@amd.com>;
> > > > > > > > > > >>> Leif Lindholm <quic_llindhol@quicinc.com>; Andrew
> > > > > > > > > > >>> Fish <afish@apple.com>
> > > > > > > > > > >>> Subject: RE: [edk2-devel] The principles of EDK2
> > > > > > > > > > >>> module reconstruction for archs
> > > > > > > > > > >>>
> > > > > > > > > > >>> Caution: This message originated from an External
> Source.
> > > > > > > > > > >>> Use proper caution when opening attachments,
> > > > > > > > > > >>> clicking links, or
> > > > > > > responding.
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>> Abner,
> > > > > > > > > > >>> Comments in
> > > > > > > > > > >>> https://nam11.safelinks.protection.outlook.com/?url=
> > > > > > > > > > >>> ht
> > > > > > > > > > >>> tps%
> > > > > > > > > > >>> 3A%2
> > > > > > > > > > >>> F%2F
> > > > > > > > > > >>> gith
> > > > > > > > > > >>> ub.com%2Ftianocore-docs%2Fedk2-
> > > > > > > > > > >>>
> CCodingStandardsSpecification%2Fpull%2F2%23pullreque
> > > > > > > > > > >>> st
> > > > > > > > > > >>> revi
> > > > > > > > > > >>> ew-
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 1124763311&amp;data=05%7C01%7CAbner.Chang%40amd.com%7Cd825e24
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 8625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82d994e183d%7C0
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> > %7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> >
> 7C%7C%7C&amp;sdata=RXxgpbEr6ivbqP1R6%2B3Rxl%2ByJAnaUJuaYYKdfCH
> > > > > > > > > > >>> 8jo8%3D&amp;reserved=0
> > > > > > > > > > >>>
> > > > > > > > > > >>> We can discuss more in tomorrow's meeting.
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>>> -----Original Message-----
> > > > > > > > > > >>>> From: Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > > >>>> <AbdulLateef.Attar@amd.com>
> > > > > > > > > > >>>> Sent: Thursday, September 29, 2022 3:11 PM
> > > > > > > > > > >>>> To: Chang, Abner <Abner.Chang@amd.com>; Sunil V L
> > > > > > > > > > >>>> <sunilvl@ventanamicro.com>; devel@edk2.groups.io;
> > > > > > > > > > >>>> Ni, Ray <ray.ni@intel.com>
> > > > > > > > > > >>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>;
> > > > > > > > > > >>>> lichao <lichao@loongson.cn>; Kirkendall, Garrett
> > > > > > > > > > >>>> <Garrett.Kirkendall@amd.com>; Grimes, Paul
> > > > > > > > > > >>>> <Paul.Grimes@amd.com>;
> > > > > > > > > > >>> He,
> > > > > > > > > > >>>> Jiangang <Jiangang.He@amd.com>; Leif Lindholm
> > > > > > > > > > >>>> <quic_llindhol@quicinc.com>; Andrew Fish
> > > > > > > > > > >>>> <afish@apple.com>
> > > > > > > > > > >>>> Subject: RE: [edk2-devel] The principles of EDK2
> > > > > > > > > > >>>> module reconstruction for archs
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Hi Abner,
> > > > > > > > > > >>>>      Looks good to me.
> > > > > > > > > > >>>> Reviewed-by:  Abdul Lateef Attar <abdattar@amd.com>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Thanks
> > > > > > > > > > >>>> AbduL
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> -----Original Message-----
> > > > > > > > > > >>>> From: Chang, Abner <Abner.Chang@amd.com>
> > > > > > > > > > >>>> Sent: 28 September 2022 20:31
> > > > > > > > > > >>>> To: Sunil V L <sunilvl@ventanamicro.com>;
> > > > > > > > > > >>>> devel@edk2.groups.io; ray.ni@intel.com
> > > > > > > > > > >>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>;
> > > > > > > > > > >>>> lichao <lichao@loongson.cn>; Kirkendall, Garrett
> > > > > > > > > > >>>> <Garrett.Kirkendall@amd.com>; Grimes, Paul
> > > > > > > > > > >>>> <Paul.Grimes@amd.com>;
> > > > > > > > > > >>> He,
> > > > > > > > > > >>>> Jiangang <Jiangang.He@amd.com>; Attar, AbdulLateef
> > > > > > > > > > >>>> (Abdul
> > > > > > > > > > >>>> Lateef) <AbdulLateef.Attar@amd.com>; Leif Lindholm
> > > > > > > > > > >>>> <quic_llindhol@quicinc.com>; Andrew Fish
> > > > > > > > > > >>>> <afish@apple.com>
> > > > > > > > > > >>>> Subject: RE: [edk2-devel] The principles of EDK2
> > > > > > > > > > >>>> module reconstruction for archs
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> [AMD Official Use Only - General]
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> I just had created PR to update edkII C coding
> > > > > > > > > > >>>> standard spec for the file and directory naming. We
> > > > > > > > > > >>>> can review and confirm this update first and then
> > > > > > > > > > >>>> go back to the principles of EDK2 module
> > > > > > > > > reconstruction for archs.
> > > > > > > > > > >>>> Here is the PR:
> > > > > > > > > > >>>>
> > > > > > > > > > >>> https://nam11.safelinks.protection.outlook.com/?url=
> > > > > > > > > > >>> ht
> > > > > > > > > > >>> tps%
> > > > > > > > > > >>> 3A%2
> > > > > > > > > > >>> F%2F
> > > > > > > > > > >>> gith
> > > > > > > > > > >>>> ub.com%2Ftianocore-docs%2Fedk2-
> > > > > > > > > > >>> &amp;data=05%7C01%7CAbner.Chang%40amd.c
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> om%7Cd825e248625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82
> > > > > > > > > > >>> d994e18
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 3d%7C0%7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJ
> > > > > > > > > > >>> WIjoiMC4wLj
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> > > > > > > > > > >>> 7C%7C&a
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> mp;sdata=X4z9puj81nIGTqtMxC9igDZyBPOT6OTWSU%2BjoIowo%2BE%3D&a
> > > > > > > > > > >>> mp;reserv
> > > > > > > > > > >>>> ed=0
> > > > > > > > > > >>>> CCodingStandardsSpecification/pull/2
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> The naming rule is mainly for the new module or new
> file
> > IMO.
> > > > > > > > > > >>>> Some existing module may not meet the guidelines
> > > > > > > > > > >>>> mentioned in this
> > > > > > > > > spec.
> > > > > > > > > > >>>> Thus we need the principles of EDK2 module
> > > > > > > > > > >>>> reconstruction on the existing module to support
> > > > > > > > > > >>>> other processor archs and not impacting the
> > > > > > > > > > >>> existing platforms (e.g.
> > > > > > > > > > >>>> rename the INF file or directory to meet the
> guidelines).
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Sunil, seems RISC-V CpuDxe meet the guideline.
> > > > > > > > > > >>>> Please check
> > > > > it.
> > > > > > > > > > >>>> Just feel that having  CpuDxe.c to Riscv64 folder
> > > > > > > > > > >>>> is not quite a best solution. I think at least we
> > > > > > > > > > >>>> can abstract the protocol structure and protocol
> > > > > > > > > > >>>> installation under CpuDxe\ and have the arch
> > > > > > > > > > >>>> implementation under arch folder. We can discuss
> > > > > > > > > > >>>> this later after we confirming the
> > > > > > > > > > >>> guideline and principles.
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Thanks
> > > > > > > > > > >>>> Abner
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>> -----Original Message-----
> > > > > > > > > > >>>>> From: Sunil V L <sunilvl@ventanamicro.com>
> > > > > > > > > > >>>>> Sent: Wednesday, September 28, 2022 3:34 PM
> > > > > > > > > > >>>>> To: devel@edk2.groups.io; ray.ni@intel.com
> > > > > > > > > > >>>>> Cc: Chang, Abner <Abner.Chang@amd.com>; Kinney,
> > > > > Michael
> > > > > > > > > > >>>>> D <michael.d.kinney@intel.com>; lichao
> > > > > > > > > > >>>>> <lichao@loongson.cn>; Kirkendall, Garrett
> > > > > > > > > > >>>>> <Garrett.Kirkendall@amd.com>; Grimes, Paul
> > > > > > > > > > >>>>> <Paul.Grimes@amd.com>; He, Jiangang
> > > > > > > > > > >>>>> <Jiangang.He@amd.com>; Attar, AbdulLateef (Abdul
> > > > > > > > > > >>>>> Lateef) <AbdulLateef.Attar@amd.com>; Leif
> Lindholm
> > > > > > > > > > >>>>> <quic_llindhol@quicinc.com>; Andrew Fish
> > > > > > > > > > >>>>> <afish@apple.com>
> > > > > > > > > > >>>>> Subject: Re: [edk2-devel] The principles of EDK2
> > > > > > > > > > >>>>> module reconstruction for archs
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> Caution: This message originated from an External
> > Source.
> > > > > > > > > > >>>>> Use proper caution when opening attachments,
> > > > > > > > > > >>>>> clicking links, or
> > > > > > > responding.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> On Wed, Sep 28, 2022 at 03:33:45AM +0000, Ni, Ray
> > wrote:
> > > > > > > > > > >>>>> Hi Ray,
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>>    1.  When a new arch's implementation is
> > > > > > > > > > >>>>>> introduced to the existing
> > > > > > > > > > >>>>> module which was developed for the specific arch:
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>>    1.  The folder reconstruction:
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>>    *   Create arch folder for the existing arch
> > implementation
> > > > > > > > > > >>>>>> [Ray] Do you move existing arch implementation to
> > > > > > > > > > >>>>>> that arch
> > > > > > > folder?
> > > > > > > > > > >>>>>> It will
> > > > > > > > > > >>>>> break existing platforms a lot.
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>>    *   Create the arch folder for the new introduced
> > arch
> > > > > > > > > > >>>>>> [Ray] I agree. But if we don't create arch folder
> > > > > > > > > > >>>>>> for existing arch
> > > > > > > > > > >>>>> implementation, the pkg layout will be a mess.
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> [Ray] Hard for me to understand all the principles
> here.
> > > > > > > > > > >>>>>> Maybe we review
> > > > > > > > > > >>>>> existing code including to-be-upstreamed code and
> > > > > > > > > > >>>>> decide how
> > > > > > > to go.
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> Could you please take a look below changes which
> > > > > > > > > > >>>>> is trying to add RISC-V support for CpuDxe?
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>> https://nam11.safelinks.protection.outlook.com/?url=
> > > > > > > > > > >>> ht
> > > > > > > > > > >>> tps%
> > > > > > > > > > >>> 3A%2
> > > > > > > > > > >>> F%2F
> > > > > > > > > > >>> gith
> > > > > > > > > > >>>>> ub.com%2Ftianocore%2Fedk2-
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> staging%2Fcommit%2Fbba1a11be47dd091734e185afbed73ea75708749&amp;
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> data=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08d
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> aa123e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 2732494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sd
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> >
> ata=Vq6pJLnn8yJrJhFZn7LfLbZzrtpG4n1VLWgAil6J38U%3D&amp;reserved=0
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>> https://nam11.safelinks.protection.outlook.com/?url=
> > > > > > > > > > >>> ht
> > > > > > > > > > >>> tps%
> > > > > > > > > > >>> 3A%2
> > > > > > > > > > >>> F%2F
> > > > > > > > > > >>> gith
> > > > > > > > > > >>>>> ub.com%2Ftianocore%2Fedk2-
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> staging%2Fcommit%2F7fccf92a97a6d0618a20f10622220e78b3687906&amp;da
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> ta=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08daa1
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 23e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947273
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 2494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> >
> =xFmvUv58vh4AUAM17Qy9G5jZWFZlK2Ozt3njpG1e8%2BY%3D&amp;reserv
> > > > > > > > > > >>>>> ed=0
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> What do you suggest with above example?
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> 1) Common INF for all architectures - but modify
> > > > > > > > > > >>>>> INF alone, no
> > > > > > > > > > >>>>> X86 folder creation.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> This is what I have done in the commit above. May
> > > > > > > > > > >>>>> be of least impact to existing code since it is only INF
> > change.
> > > > > > > > > > >>>>> But like you mentioned this is bit weird that X86
> > > > > > > > > > >>>>> files will remain in root folder directly along
> > > > > > > > > > >>>>> with some common
> > > > > files.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> 2) Common INF (CpuDxe.inf) + create arch folders
> > > > > > > > > > >>>>> X86, X64, IA32,
> > > > > > > > > > >>>>> RiscV64 etc
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> IMO, this is probably the best approach. What
> > > > > > > > > > >>>>> would be the challenges with this?
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> 3) Separate INF for arch like CpuDxe.inf for x86,
> > > > > > > > > > >>>>> CpuDxeRiscV64.inf for
> > > > > > > > > > >>>> RISC-V.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> This again probably is not a good idea.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> 4) If the module/library is specific to one arch (ex:
> > > > > > > > > > >>>>> SMM(X86), SBI(RISC-V)), then create separate INF.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> Thanks!
> > > > > > > > > > >>>>> Sunil
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >