[edk2-devel] The principles of EDK2 module reconstruction for archs
Chang, Abner via groups.io
abner.chang=amd.com at groups.io
Thu Oct 6 08:37:15 UTC 2022
[AMD Official Use Only - General]
Here is the update of the Wiki page for the consistency with edk2 C Coding Standard Spec.
https://github.com/changab/tianocore.github.io/wiki/The-Guidelines-of-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 at intel.com>; devel at edk2.groups.io;
> quic_llindhol at quicinc.com; Ni, Ray <ray.ni at intel.com>; Attar, AbdulLateef
> (Abdul Lateef) <AbdulLateef.Attar at amd.com>; Sunil V L
> <sunilvl at ventanamicro.com>
> Cc: lichao <lichao at loongson.cn>; Kirkendall, Garrett
> <Garrett.Kirkendall at amd.com>; Grimes, Paul <Paul.Grimes at amd.com>; He,
> Jiangang <Jiangang.He at amd.com>; Andrew Fish <afish at apple.com>
> Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for
> archs
>
> [AMD Official Use Only - General]
>
> PR updated
> https://github.com/tianocore-docs/edk2-
> CCodingStandardsSpecification/pull/2/commits. Please check it.
>
> Thanks
> Abner
>
> > -----Original Message-----
> > From: Kinney, Michael D <michael.d.kinney at intel.com>
> > Sent: Tuesday, October 4, 2022 10:18 PM
> > To: Chang, Abner <Abner.Chang at amd.com>; devel at edk2.groups.io;
> > quic_llindhol at quicinc.com; Ni, Ray <ray.ni at intel.com>; Attar,
> > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar at amd.com>; Sunil V L
> > <sunilvl at ventanamicro.com>; Kinney, Michael D
> > <michael.d.kinney at intel.com>
> > Cc: lichao <lichao at loongson.cn>; Kirkendall, Garrett
> > <Garrett.Kirkendall at amd.com>; Grimes, Paul <Paul.Grimes at amd.com>;
> He,
> > Jiangang <Jiangang.He at amd.com>; Andrew Fish <afish at 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 at amd.com>
> > > Sent: Tuesday, October 4, 2022 7:05 AM
> > > To: Kinney, Michael D <michael.d.kinney at intel.com>;
> > > devel at edk2.groups.io; quic_llindhol at quicinc.com; Ni, Ray
> > > <ray.ni at intel.com>; Attar, AbdulLateef (Abdul Lateef)
> > > <AbdulLateef.Attar at amd.com>; Sunil V L <sunilvl at ventanamicro.com>
> > > Cc: lichao <lichao at loongson.cn>; Kirkendall, Garrett
> > > <Garrett.Kirkendall at amd.com>; Grimes, Paul <Paul.Grimes at amd.com>;
> > > He, Jiangang <Jiangang.He at amd.com>; Andrew Fish <afish at 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 at intel.com>
> > > > Sent: Tuesday, October 4, 2022 12:54 AM
> > > > To: devel at edk2.groups.io; Chang, Abner <Abner.Chang at amd.com>;
> > > > quic_llindhol at quicinc.com; Ni, Ray <ray.ni at intel.com>; Attar,
> > > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar at amd.com>; Sunil V L
> > > > <sunilvl at ventanamicro.com>; Kinney, Michael D
> > > > <michael.d.kinney at intel.com>
> > > > Cc: lichao <lichao at loongson.cn>; Kirkendall, Garrett
> > > > <Garrett.Kirkendall at amd.com>; Grimes, Paul
> <Paul.Grimes at amd.com>;
> > > > He, Jiangang <Jiangang.He at amd.com>; Andrew Fish
> <afish at 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 at edk2.groups.io <devel at 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 at intel.com>;
> > > > > devel at edk2.groups.io; quic_llindhol at quicinc.com; Ni, Ray
> > > > > <ray.ni at intel.com>; Attar, AbdulLateef (Abdul Lateef)
> > > > > <AbdulLateef.Attar at amd.com>; Sunil V L
> > > > > <sunilvl at ventanamicro.com>
> > > > > Cc: lichao <lichao at loongson.cn>; Kirkendall, Garrett
> > > > > <Garrett.Kirkendall at amd.com>; Grimes, Paul
> > > > > <Paul.Grimes at amd.com>;
> > > > He,
> > > > > Jiangang <Jiangang.He at amd.com>; Andrew Fish <afish at 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 at intel.com>
> > > > > > Sent: Monday, October 3, 2022 1:18 PM
> > > > > > To: Chang, Abner <Abner.Chang at amd.com>;
> devel at edk2.groups.io;
> > > > > > quic_llindhol at quicinc.com; Ni, Ray <ray.ni at intel.com>; Attar,
> > > > > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar at amd.com>; Sunil
> > > > > > V L <sunilvl at ventanamicro.com>; Kinney, Michael D
> > > > > > <michael.d.kinney at intel.com>
> > > > > > Cc: lichao <lichao at loongson.cn>; Kirkendall, Garrett
> > > > > > <Garrett.Kirkendall at amd.com>; Grimes, Paul
> > > > > > <Paul.Grimes at amd.com>; He, Jiangang <Jiangang.He at amd.com>;
> > > > > > Andrew Fish <afish at 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 at amd.com>
> > > > > > > Sent: Sunday, October 2, 2022 8:13 PM
> > > > > > > To: Kinney, Michael D <michael.d.kinney at intel.com>;
> > > > > > > devel at edk2.groups.io; quic_llindhol at quicinc.com; Ni, Ray
> > > > > > > <ray.ni at intel.com>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > > <AbdulLateef.Attar at amd.com>; Sunil V L
> > > > > > > <sunilvl at ventanamicro.com>
> > > > > > > Cc: lichao <lichao at loongson.cn>; Kirkendall, Garrett
> > > > > > > <Garrett.Kirkendall at amd.com>; Grimes, Paul
> > > > <Paul.Grimes at amd.com>;
> > > > > > He,
> > > > > > > Jiangang <Jiangang.He at amd.com>; Andrew Fish
> > > > > > > <afish at 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&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&sdata=eiLOC0G9WZWKqm2ALcAiKr7SPBP5AgDdAxogHlv5pI
> > > > > > M%3D&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 at intel.com>
> > > > > > > > Sent: Saturday, October 1, 2022 2:52 AM
> > > > > > > > To: devel at edk2.groups.io; quic_llindhol at quicinc.com;
> > > > > > > > Chang, Abner <Abner.Chang at amd.com>; Ni, Ray
> > > > > > > > <ray.ni at intel.com>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > <AbdulLateef.Attar at amd.com>; Sunil V L
> > > > > > > > <sunilvl at ventanamicro.com>; Kinney, Michael D
> > > > > > > > <michael.d.kinney at intel.com>
> > > > > > > > Cc: lichao <lichao at loongson.cn>; Kirkendall, Garrett
> > > > > > > > <Garrett.Kirkendall at amd.com>; Grimes, Paul
> > > > > > > > <Paul.Grimes at amd.com>; He, Jiangang
> <Jiangang.He at amd.com>;
> > > > > > > > Andrew Fish <afish at 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 at edk2.groups.io <devel at edk2.groups.io> On
> > > > > > > > > Behalf Of Leif Lindholm
> > > > > > > > > Sent: Friday, September 30, 2022 9:09 AM
> > > > > > > > > To: devel at edk2.groups.io; Kinney, Michael D
> > > > > > > > > <michael.d.kinney at intel.com>; Chang, Abner
> > > > > > <Abner.Chang at amd.com>;
> > > > > > > > > Ni, Ray <ray.ni at intel.com>; Attar, AbdulLateef (Abdul
> > > > > > > > > Lateef) <AbdulLateef.Attar at amd.com>; Sunil V L
> > > > > > > > > <sunilvl at ventanamicro.com>
> > > > > > > > > Cc: lichao <lichao at loongson.cn>; Kirkendall, Garrett
> > > > > > > > > <Garrett.Kirkendall at amd.com>; Grimes, Paul
> > > > > > <Paul.Grimes at amd.com>;
> > > > > > > > > He, Jiangang <Jiangang.He at amd.com>; Andrew Fish
> > > > > > <afish at 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 at amd.com>
> > > > > > > > > >> Sent: Friday, September 30, 2022 12:11 AM
> > > > > > > > > >> To: Ni, Ray <ray.ni at intel.com>; Attar, AbdulLateef
> > > > > > > > > >> (Abdul
> > > > > > > > > >> Lateef) <AbdulLateef.Attar at amd.com>; Sunil V L
> > > > > > > > > >> <sunilvl at ventanamicro.com>; devel at edk2.groups.io;
> > > > > > > > > >> Kinney, Michael D <michael.d.kinney at intel.com>
> > > > > > > > > >> Cc: lichao <lichao at loongson.cn>; Kirkendall, Garrett
> > > > > > > > > >> <Garrett.Kirkendall at amd.com>; Grimes, Paul
> > > > > > > > > >> <Paul.Grimes at amd.com>; He, Jiangang
> > > > <Jiangang.He at amd.com>;
> > > > > > Leif
> > > > > > > > > >> Lindholm <quic_llindhol at quicinc.com>; Andrew Fish
> > > > > > > > > >> <afish at 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&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&sdata
> > > > > > =
> > > > > > > > HAq
> > > > > > > > > >>
> > > > > >
> > > >
> ou4JyY1yxDthuQ1dEKcF7Q3o4W77Oo9rOOvkXNWU%3D&reserved=0
> > > > > > > > > >>
> > > > > > > > > >> @Kinney, Michael D we may also need your
> > > > > > > > > >> clarification on the
> > > > > > comments.
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>> -----Original Message-----
> > > > > > > > > >>> From: Ni, Ray <ray.ni at intel.com>
> > > > > > > > > >>> Sent: Thursday, September 29, 2022 3:42 PM
> > > > > > > > > >>> To: Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > >>> <AbdulLateef.Attar at amd.com>; Chang, Abner
> > > > > > > > > >>> <Abner.Chang at amd.com>; Sunil V L
> > > > > > > > > >>> <sunilvl at ventanamicro.com>; devel at edk2.groups.io
> > > > > > > > > >>> Cc: Kinney, Michael D <michael.d.kinney at intel.com>;
> > > > > > > > > >>> lichao <lichao at loongson.cn>; Kirkendall, Garrett
> > > > > > > > > >>> <Garrett.Kirkendall at amd.com>; Grimes, Paul
> > > > > > > > > >>> <Paul.Grimes at amd.com>; He, Jiangang
> > > > <Jiangang.He at amd.com>;
> > > > > > > > > >>> Leif Lindholm <quic_llindhol at quicinc.com>; Andrew
> > > > > > > > > >>> Fish <afish at 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&data=05%7C01%7CAbner.Chang%40amd.com%7Cd825e24
> > > > > > > > > >>>
> > > > > > > >
> > > > > >
> > > >
> >
> 8625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82d994e183d%7C0
> > > > > > > > > >>>
> > > > > > > >
> > > > > >
> > > >
> >
> %7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> > > > > > > > > >>>
> > > > > > > >
> > > > > >
> > > >
> >
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> > > > > > > > > >>>
> > > > > > > >
> > > > > >
> > > >
> 7C%7C%7C&sdata=RXxgpbEr6ivbqP1R6%2B3Rxl%2ByJAnaUJuaYYKdfCH
> > > > > > > > > >>> 8jo8%3D&reserved=0
> > > > > > > > > >>>
> > > > > > > > > >>> We can discuss more in tomorrow's meeting.
> > > > > > > > > >>>
> > > > > > > > > >>>
> > > > > > > > > >>>> -----Original Message-----
> > > > > > > > > >>>> From: Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > >>>> <AbdulLateef.Attar at amd.com>
> > > > > > > > > >>>> Sent: Thursday, September 29, 2022 3:11 PM
> > > > > > > > > >>>> To: Chang, Abner <Abner.Chang at amd.com>; Sunil V L
> > > > > > > > > >>>> <sunilvl at ventanamicro.com>; devel at edk2.groups.io;
> > > > > > > > > >>>> Ni, Ray <ray.ni at intel.com>
> > > > > > > > > >>>> Cc: Kinney, Michael D <michael.d.kinney at intel.com>;
> > > > > > > > > >>>> lichao <lichao at loongson.cn>; Kirkendall, Garrett
> > > > > > > > > >>>> <Garrett.Kirkendall at amd.com>; Grimes, Paul
> > > > > > > > > >>>> <Paul.Grimes at amd.com>;
> > > > > > > > > >>> He,
> > > > > > > > > >>>> Jiangang <Jiangang.He at amd.com>; Leif Lindholm
> > > > > > > > > >>>> <quic_llindhol at quicinc.com>; Andrew Fish
> > > > > > > > > >>>> <afish at 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 at amd.com>
> > > > > > > > > >>>>
> > > > > > > > > >>>> Thanks
> > > > > > > > > >>>> AbduL
> > > > > > > > > >>>>
> > > > > > > > > >>>> -----Original Message-----
> > > > > > > > > >>>> From: Chang, Abner <Abner.Chang at amd.com>
> > > > > > > > > >>>> Sent: 28 September 2022 20:31
> > > > > > > > > >>>> To: Sunil V L <sunilvl at ventanamicro.com>;
> > > > > > > > > >>>> devel at edk2.groups.io; ray.ni at intel.com
> > > > > > > > > >>>> Cc: Kinney, Michael D <michael.d.kinney at intel.com>;
> > > > > > > > > >>>> lichao <lichao at loongson.cn>; Kirkendall, Garrett
> > > > > > > > > >>>> <Garrett.Kirkendall at amd.com>; Grimes, Paul
> > > > > > > > > >>>> <Paul.Grimes at amd.com>;
> > > > > > > > > >>> He,
> > > > > > > > > >>>> Jiangang <Jiangang.He at amd.com>; Attar, AbdulLateef
> > > > > > > > > >>>> (Abdul
> > > > > > > > > >>>> Lateef) <AbdulLateef.Attar at amd.com>; Leif Lindholm
> > > > > > > > > >>>> <quic_llindhol at quicinc.com>; Andrew Fish
> > > > > > > > > >>>> <afish at 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-
> > > > > > > > > >>> &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 at ventanamicro.com>
> > > > > > > > > >>>>> Sent: Wednesday, September 28, 2022 3:34 PM
> > > > > > > > > >>>>> To: devel at edk2.groups.io; ray.ni at intel.com
> > > > > > > > > >>>>> Cc: Chang, Abner <Abner.Chang at amd.com>; Kinney,
> > > > Michael
> > > > > > > > > >>>>> D <michael.d.kinney at intel.com>; lichao
> > > > > > > > > >>>>> <lichao at loongson.cn>; Kirkendall, Garrett
> > > > > > > > > >>>>> <Garrett.Kirkendall at amd.com>; Grimes, Paul
> > > > > > > > > >>>>> <Paul.Grimes at amd.com>; He, Jiangang
> > > > > > > > > >>>>> <Jiangang.He at amd.com>; Attar, AbdulLateef (Abdul
> > > > > > > > > >>>>> Lateef) <AbdulLateef.Attar at amd.com>; Leif Lindholm
> > > > > > > > > >>>>> <quic_llindhol at quicinc.com>; Andrew Fish
> > > > > > > > > >>>>> <afish at 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&
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>
> > > > > > > >
> > > > > >
> > > >
> >
> data=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08d
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>
> > > > > > > >
> > > > > >
> > > >
> >
> aa123e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>
> > > > > > > >
> > > > > >
> > > >
> >
> 2732494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>
> > > > > > > >
> > > > > >
> > > >
> >
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>
> > > > > > > >
> > > > > >
> > > >
> ata=Vq6pJLnn8yJrJhFZn7LfLbZzrtpG4n1VLWgAil6J38U%3D&reserved=0
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>> https://nam11.safelinks.protection.outlook.com/?url=
> > > > > > > > > >>> ht
> > > > > > > > > >>> tps%
> > > > > > > > > >>> 3A%2
> > > > > > > > > >>> F%2F
> > > > > > > > > >>> gith
> > > > > > > > > >>>>> ub.com%2Ftianocore%2Fedk2-
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>
> > > > > > > >
> > > > > >
> > > >
> >
> staging%2Fcommit%2F7fccf92a97a6d0618a20f10622220e78b3687906&da
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>
> > > > > > > >
> > > > > >
> > > >
> >
> ta=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08daa1
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>
> > > > > > > >
> > > > > >
> > > >
> >
> 23e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947273
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>
> > > > > > > >
> > > > > >
> > > >
> >
> 2494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>
> > > > > > > >
> > > > > >
> > > >
> >
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>
> > > > > > > >
> > > > > >
> > > >
> =xFmvUv58vh4AUAM17Qy9G5jZWFZlK2Ozt3njpG1e8%2BY%3D&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
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94783): https://edk2.groups.io/g/devel/message/94783
Mute This Topic: https://groups.io/mt/93872791/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-
More information about the edk2-devel-archive
mailing list