Re: [edk2-devel] The principles of EDK2 module reconstruction for archs

["Chang, Abner" <abner.chang@amd.com>]

[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%2Fed
> > > k
> > > 2
> > >
> > .groups.io%2Fg%2Fdevel%2Fmessage%2F94567&amp;data=05%7C01%7CA
> > > 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=https%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=https%
> > > > > > >>> 3A%2
> > > > > > >>> F%2F
> > > > > > >>> gith
> > > > > > >>> ub.com%2Ftianocore-docs%2Fedk2-
> > > > > > >>> CCodingStandardsSpecification%2Fpull%2F2%23pullrequestrevi
> > > > > > >>> ew-
> > > > > > >>>
> > > > >
> > >
> 1124763311&amp;data=05%7C01%7CAbner.Chang%40amd.com%7Cd825e24
> > > > > > >>>
> > > > >
> > >
> 8625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82d994e183d%7C0
> > > > > > >>>
> > > > >
> > >
> %7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> > > > > > >>>
> > > > >
> > >
> 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=https%
> > > > > > >>> 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=https%
> > > > > > >>> 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=https%
> > > > > > >>> 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> >
> >
> > 
> >