The principles of EDK2 module reconstruction for archs

The principles of EDK2 module reconstruction for archs

[Chang, Abner]

[-- Attachment #1: Type: text/plain, Size: 7481 bytes --]

[AMD Official Use Only - General]

All,
Today in edk2 open design meeting, we went through the draft of principles of the EDK2 module reconstruction for accommodating different archs (IA32, X64, Arm, AArch64, RiscV64, Loongson64 and etc.) or different vendors of the same arch (AMD/Intel to IA32 and X64).

@Ray Ni<mailto:ray.ni@intel.com> and @michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>

  1.  We may need somewhere on edk2 repo or another place that can have PR for the easy review, please let me know where I can create the PR instead of reviewing this through dev mailing list.
  2.  I didn't mention using CPUID, Family ID or PCD to have the different code path for AMD and Intel. The reason is,
     *   This decreases the readability of code.
     *   That makes a confusing to the review process

                                                    i.     Says the maintainer/reviewer owns the package, however the patch is specific to AMD implementation but the change is in the file that mixes up Intel and AMD code. Then who is supposed the right person to give the reviewed-by? Perhaps the AMD edk2 module maintainers or reviewers is the proper person to give the reviewed-by for this case. Of course, other maintainers still can join the review process and give the comments. So to separate the arch-specific code in a arch-specific source file simplifies the review, even that is just a small delta between two implementations.

                                                   ii.     We can have the maintainers or reviewers for the entire module or *Amd* files only. So the maintainers/reviewers do not have to review the changes that only made for other archs. But they have to help reviewing the common code if that gets impact.

  1.  I didn't mention to have <phase><arch><basename> for the new module. I prefer we just inherit the original module name or file name so we can know the module or the source file has the different implementation for archs in the file browser (when the files are sorted in alphabet).


Lets discuss this using PR if possible.
Thanks
Abner


Below is the draft of principles:

Preface:
The principle is mainly for UefiCpuPKg, but the same principle maybe applied to the EDK2 module that has the processor architecture dependence (such as the BaseLib under MdePkg/Library). Most of the EDK2 modules under UefiCpuPkg were developed specifically to IA32/X64 architecture, that is necessary to reconstruct the folder or revise the source files to accommodate other processor architectures. The EDK2 module reconstruction is also required for accommodating the same-arch-but-different-vendor's implementation (e.g., Intel and AMD for the X86 based processors). The EDK2 module may be strictly developed based on the specific processor architecture. The new introduced implementation for other processor architectures may consider to have a separate EDK2 module instance. Not all of the EDK2 modules revising can exactly meet the principles listed below, that depends on the delta between the original EDK2 module and the implementation for the new introduced processor architecture. It may require the further discussions with EDK2 module maintainers.

The [Arch] refers to the Processor Architecture.
The [Module] refer to the EDK2 module.
The [X86] refers to both IA32 and X64.

The principles to create the X86 folder in the module:

  1.  When X86-vendor's implementation is introduced to the existing module:

  1.  The folder reconstruction:
A-1. If the module is obviously used by IA32/X64 only

  *   No need to create X86 folder
  *   Create X86-vendor's stuff under the root directory of module
A-2. If the existing module is expected to accommodate the different archs or the module already has multiple archs:

  *   Create X86 folder
  *   Create X86-vendor's stuff under X86 folder


  1.  The files reconstruction:
B-1. The module INF metafile

  *   The existing INF metafile should be kept without relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.
     *   <OriginalFileName><arch>.inf


                     B-2. Source files
                              The new arch implementation is introduced to the module in order to leverage the source code and the module design architecture, so

  *   That is contributor's responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific and arch-specific-feature wordings in the file name. Create a common file for the common implementation otherwise.
     *   The file naming for the arch-specific file

<OriginalFileName ><arch>.*

     *   The file naming for the common implementation

< OriginalFileNaming >Common.*

  *   That is contributor's responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor's responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module


  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
  *   Create the arch folder for the new introduced arch



  1.  The files reconstruction:

B-1. The module INF metafile

  *   The existing INF file should be kept without the relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.
     *   < OriginalFileNaming><arch>.inf



B-2. Source files
                             The new arch implementation is introduced to this module in order to leverage the source code and the module design architecture, so

  *   That is contributor's responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific wording in the file name. Create a common file for the common implementation otherwise.
     *   The file naming for the arch-specific source file

< OriginalFileNaming ><arch>.*

     *   The file naming for the common implementation

<OriginalFileNaming>Common.*

  *   That is contributor's responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor's responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module



  1.  When a new arch implementation has a huge delta with the original implementation

Create a separate module instance. The naming of the module should follow below format,

  *   Add the arch prefix with the original module name:

< OriginalModuleNaming><arch>


[-- Attachment #2: Type: text/html, Size: 31714 bytes --]

Re: The principles of EDK2 module reconstruction for archs

[Michael D Kinney]

[-- Attachment #1: Type: text/plain, Size: 12213 bytes --]

Hi Abner,

I think it would be good to clarify when a difference in implementation is due to a CPU Arch difference or a Vendor implementation difference.

I would also be good to provide guidelines for directory names and file names for all EDK II meta data file types.  Here are some examples to get started:

Package Directory Name:                             <PackageName>Pkg
Package DEC File Name:                                 <PackageName>Pkg.dec

                <PackageName>              REQUIRED           *

Module Directory Name:                              <ModuleName><Phase>
                                                                                < Feature >/<Phase>
Module INF File Name:                                  <ModuleName><Phase>.inf
                                                                                < Feature>/<Phase>/<ModuleName>.inf

                <Feature>                           OPTIONAL           Only used if implementation does not have any shared code between phases (e.g. MdeModulePkg/Universal/PCD)
                <Phase>                              REQUIRED           Base, Sec, Pei, Dxe, DxeRuntime, Mm, StandaloneMm, Smm, Uefi
                <ModuleName>               REQUIRED           *

Library Instance Directory Name:              <Phase><CpuArch><Vendor><LibraryClassName><Dependency>
Library Instance INF File Name:                  <Phase><CpuArch><Vendor><LibraryClassName><Dependency>.inf

                <Phase>                              REQUIRED           Base, Sec, Pei, Dxe, DxeRuntime, Mm, StandaloneMm, Smm, Uefi
                <CpuArch>                         OPTIONAL           Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc                                        If not provided, then component supports >=2 or all CPU archs
                <Vendor>                           OPTIONAL           *
                <LibraryClassName>       REQUIRED           *
                <Dependency>                 OPTIONAL           *             Typically name of PPI, Protocol, LibraryClass that the implementation is layered on top of.

Source File Paths within a Library/Module instance
                <FileName>.c
                <FileName>.h
                <CpuArch>/<FileName>.c
                <CpuArch>/<FileName>.h
                <CpuArch>/<FileName>.nasm
                <CpuArch>/<FileName>.S

                <CpuArch>                         OPTIONAL           Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc

I think the point you are raising in the discussion is that sometimes there may be shared content between a small subset of CPU archs (e.g. IA32/X64 or Arm/AArch64 or RiscV32/RiscV64/RiscV128) and that you are proposing a new standard directory name for these combinations.  Your proposal is X86 for a directory that contains content for both IA32 and X64.  You are also wanting to support vendor specific content in the naming convention.  An example where it is already being done is in MdePkg/Include/Registers/<VendorName>.   So an enhancement to the above Source File Paths would be:

Source File Paths within a Library/Module instance
                <FileName>.c
                <FileName>.h
                <CpuArch>/<FileName>.c
                <CpuArch>/<FileName>.h
                <CpuArch>/<FileName>.nasm
                <CpuArch>/<FileName>.S
                <CpuArch>/<Vendor>/<FileName>.c
                <CpuArch>/<Vendor>/<FileName>.h
                <CpuArch>/<Vendor>/<FileName>.nasm
                <CpuArch>/<Vendor>/<FileName>.S

                <CpuArch>                         OPTIONAL           Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc, X86
                <Vendor>                           OPTIONAL           *

I am not sure if we should use “Common” in the naming conventions.  I think by default, any content that is not CpuArch or Vendor specific could be considered common content.

Thanks,

Mike

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Chang, Abner via groups.io
Sent: Friday, September 23, 2022 8:39 AM
To: devel@edk2.groups.io
Cc: Ni, Ray <ray.ni@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Sunil V L <sunilvl@ventanamicro.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: [edk2-devel] The principles of EDK2 module reconstruction for archs


[AMD Official Use Only - General]

All,
Today in edk2 open design meeting, we went through the draft of principles of the EDK2 module reconstruction for accommodating different archs (IA32, X64, Arm, AArch64, RiscV64, Loongson64 and etc.) or different vendors of the same arch (AMD/Intel to IA32 and X64).

@Ray Ni<mailto:ray.ni@intel.com> and @michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>

  1.  We may need somewhere on edk2 repo or another place that can have PR for the easy review, please let me know where I can create the PR instead of reviewing this through dev mailing list.
  2.  I didn’t mention using CPUID, Family ID or PCD to have the different code path for AMD and Intel. The reason is,
     *   This decreases the readability of code.
     *   That makes a confusing to the review process

                                                               i.      Says the maintainer/reviewer owns the package, however the patch is specific to AMD implementation but the change is in the file that mixes up Intel and AMD code. Then who is supposed the right person to give the reviewed-by? Perhaps the AMD edk2 module maintainers or reviewers is the proper person to give the reviewed-by for this case. Of course, other maintainers still can join the review process and give the comments. So to separate the arch-specific code in a arch-specific source file simplifies the review, even that is just a small delta between two implementations.

                                                             ii.      We can have the maintainers or reviewers for the entire module or *Amd* files only. So the maintainers/reviewers do not have to review the changes that only made for other archs. But they have to help reviewing the common code if that gets impact.

  1.  I didn’t mention to have <phase><arch><basename> for the new module. I prefer we just inherit the original module name or file name so we can know the module or the source file has the different implementation for archs in the file browser (when the files are sorted in alphabet).


Lets discuss this using PR if possible.
Thanks
Abner


Below is the draft of principles:

Preface:
The principle is mainly for UefiCpuPKg, but the same principle maybe applied to the EDK2 module that has the processor architecture dependence (such as the BaseLib under MdePkg/Library). Most of the EDK2 modules under UefiCpuPkg were developed specifically to IA32/X64 architecture, that is necessary to reconstruct the folder or revise the source files to accommodate other processor architectures. The EDK2 module reconstruction is also required for accommodating the same-arch-but-different-vendor’s implementation (e.g., Intel and AMD for the X86 based processors). The EDK2 module may be strictly developed based on the specific processor architecture. The new introduced implementation for other processor architectures may consider to have a separate EDK2 module instance. Not all of the EDK2 modules revising can exactly meet the principles listed below, that depends on the delta between the original EDK2 module and the implementation for the new introduced processor architecture. It may require the further discussions with EDK2 module maintainers.

The [Arch] refers to the Processor Architecture.
The [Module] refer to the EDK2 module.
The [X86] refers to both IA32 and X64.

The principles to create the X86 folder in the module:

  1.  When X86-vendor’s implementation is introduced to the existing module:

  1.  The folder reconstruction:
A-1. If the module is obviously used by IA32/X64 only

  *   No need to create X86 folder
  *   Create X86-vendor’s stuff under the root directory of module
A-2. If the existing module is expected to accommodate the different archs or the module already has multiple archs:

  *   Create X86 folder
  *   Create X86-vendor’s stuff under X86 folder


  1.  The files reconstruction:
B-1. The module INF metafile

  *   The existing INF metafile should be kept without relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.
     *   <OriginalFileName><arch>.inf


                     B-2. Source files
                              The new arch implementation is introduced to the module in order to leverage the source code and the module design architecture, so

  *   That is contributor’s responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific and arch-specific-feature wordings in the file name. Create a common file for the common implementation otherwise.
     *   The file naming for the arch-specific file

<OriginalFileName ><arch>.*

     *   The file naming for the common implementation

< OriginalFileNaming >Common.*

  *   That is contributor’s responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor’s responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module


  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
  *   Create the arch folder for the new introduced arch



  1.  The files reconstruction:

B-1. The module INF metafile

  *   The existing INF file should be kept without the relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.
     *   < OriginalFileNaming><arch>.inf



B-2. Source files
                             The new arch implementation is introduced to this module in order to leverage the source code and the module design architecture, so

  *   That is contributor’s responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific wording in the file name. Create a common file for the common implementation otherwise.
     *   The file naming for the arch-specific source file

< OriginalFileNaming ><arch>.*

     *   The file naming for the common implementation

<OriginalFileNaming>Common.*

  *   That is contributor’s responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor’s responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module



  1.  When a new arch implementation has a huge delta with the original implementation

Create a separate module instance. The naming of the module should follow below format,

  *   Add the arch prefix with the original module name:

< OriginalModuleNaming><arch>



[-- Attachment #2: Type: text/html, Size: 93986 bytes --]

Re: The principles of EDK2 module reconstruction for archs

[Chang, Abner]

[-- Attachment #1: Type: text/plain, Size: 15355 bytes --]

[AMD Official Use Only - General]

Thanks for the reply Mike,
>>> I think it would be good to clarify when a difference in implementation is due to a CPU Arch difference or a Vendor implementation difference.
Right, we can have a paragraph to clarify the difference of CPU Arch or a vendor implementation of the same CPU Arch.

If the difference of CPU Arch or a vendor implementation triggers the module reconstruction; and it is a new module or the delta is huge to share the same module, then the file/module name should follow the naming rule you listed above.
It the difference could be added to the existing module, then I think we just keep the existing naming of the file/module to prevent from introducing the impacts on the existing platform or projects meta files.

>>>I am not sure if we should use "Common" in the naming conventions.  I think by default, any content that is not CpuArch or Vendor specific could be considered common content.
Yes agree. The existing file could be a common file if there is no CpuArch or Vendor tag in the file/module name. However, there would be four scenarios,

  1.  CpuArch or vendor specific tag in the existing module/file name and some of the code could be leverage by other arch/vendor:

Strip away the share code and put it into new file and name it without arch/vendor tag. We don't need "common" in the file name.

  1.  No CpuArch or vendor specific tag in the existing module/file name and some of the code could be leverage by other arch/vendor:

Strip away the arch/vendor specific code and put it into new file named with arch/vendor tag.

  1.  No CpuArch or vendor specific tag in the existing module/file name and the code can be fully leveraged.

Keep it without any change on file/module name.

  1.  If the existing file has the "Common" tag, then just keep it as it.

How is it?

I will revise the doc. I don't see the good place to create this doc and PR for the review online. I would just create a markdown file under tianocore.github.io/docs just for the temporary. Any other suggestions?

Thanks
Abner



From: Kinney, Michael D <michael.d.kinney@intel.com>
Sent: Saturday, September 24, 2022 2:01 AM
To: devel@edk2.groups.io; Chang, Abner <Abner.Chang@amd.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Ni, Ray <ray.ni@intel.com>; Sunil V L <sunilvl@ventanamicro.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: 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,

I think it would be good to clarify when a difference in implementation is due to a CPU Arch difference or a Vendor implementation difference.

I would also be good to provide guidelines for directory names and file names for all EDK II meta data file types.  Here are some examples to get started:

Package Directory Name:                          <PackageName>Pkg
Package DEC File Name:                                            <PackageName>Pkg.dec

             <PackageName>              REQUIRED           *

Module Directory Name:                           <ModuleName><Phase>
                                                                         < Feature >/<Phase>
Module INF File Name:                              <ModuleName><Phase>.inf
                                                                         < Feature>/<Phase>/<ModuleName>.inf

             <Feature>                           OPTIONAL           Only used if implementation does not have any shared code between phases (e.g. MdeModulePkg/Universal/PCD)
             <Phase>                              REQUIRED           Base, Sec, Pei, Dxe, DxeRuntime, Mm, StandaloneMm, Smm, Uefi
             <ModuleName>                REQUIRED           *

Library Instance Directory Name:             <Phase><CpuArch><Vendor><LibraryClassName><Dependency>
Library Instance INF File Name:              <Phase><CpuArch><Vendor><LibraryClassName><Dependency>.inf

             <Phase>                              REQUIRED           Base, Sec, Pei, Dxe, DxeRuntime, Mm, StandaloneMm, Smm, Uefi
             <CpuArch>                         OPTIONAL           Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc                                        If not provided, then component supports >=2 or all CPU archs
             <Vendor>                           OPTIONAL           *
             <LibraryClassName>        REQUIRED           *
             <Dependency>                  OPTIONAL           *             Typically name of PPI, Protocol, LibraryClass that the implementation is layered on top of.

Source File Paths within a Library/Module instance
             <FileName>.c
             <FileName>.h
             <CpuArch>/<FileName>.c
             <CpuArch>/<FileName>.h
             <CpuArch>/<FileName>.nasm
             <CpuArch>/<FileName>.S

             <CpuArch>                         OPTIONAL           Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc

I think the point you are raising in the discussion is that sometimes there may be shared content between a small subset of CPU archs (e.g. IA32/X64 or Arm/AArch64 or RiscV32/RiscV64/RiscV128) and that you are proposing a new standard directory name for these combinations.  Your proposal is X86 for a directory that contains content for both IA32 and X64.  You are also wanting to support vendor specific content in the naming convention.  An example where it is already being done is in MdePkg/Include/Registers/<VendorName>.   So an enhancement to the above Source File Paths would be:

Source File Paths within a Library/Module instance
             <FileName>.c
             <FileName>.h
             <CpuArch>/<FileName>.c
             <CpuArch>/<FileName>.h
             <CpuArch>/<FileName>.nasm
             <CpuArch>/<FileName>.S
             <CpuArch>/<Vendor>/<FileName>.c
             <CpuArch>/<Vendor>/<FileName>.h
             <CpuArch>/<Vendor>/<FileName>.nasm
             <CpuArch>/<Vendor>/<FileName>.S

             <CpuArch>                         OPTIONAL           Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc, X86
             <Vendor>                           OPTIONAL           *

I am not sure if we should use "Common" in the naming conventions.  I think by default, any content that is not CpuArch or Vendor specific could be considered common content.

Thanks,

Mike

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Chang, Abner via groups.io
Sent: Friday, September 23, 2022 8:39 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Leif Lindholm <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
Subject: [edk2-devel] The principles of EDK2 module reconstruction for archs


[AMD Official Use Only - General]

All,
Today in edk2 open design meeting, we went through the draft of principles of the EDK2 module reconstruction for accommodating different archs (IA32, X64, Arm, AArch64, RiscV64, Loongson64 and etc.) or different vendors of the same arch (AMD/Intel to IA32 and X64).

@Ray Ni<mailto:ray.ni@intel.com> and @michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>

  1.  We may need somewhere on edk2 repo or another place that can have PR for the easy review, please let me know where I can create the PR instead of reviewing this through dev mailing list.
  2.  I didn't mention using CPUID, Family ID or PCD to have the different code path for AMD and Intel. The reason is,

     *   This decreases the readability of code.
     *   That makes a confusing to the review process

                                                       i.     Says the maintainer/reviewer owns the package, however the patch is specific to AMD implementation but the change is in the file that mixes up Intel and AMD code. Then who is supposed the right person to give the reviewed-by? Perhaps the AMD edk2 module maintainers or reviewers is the proper person to give the reviewed-by for this case. Of course, other maintainers still can join the review process and give the comments. So to separate the arch-specific code in a arch-specific source file simplifies the review, even that is just a small delta between two implementations.

                                                      ii.     We can have the maintainers or reviewers for the entire module or *Amd* files only. So the maintainers/reviewers do not have to review the changes that only made for other archs. But they have to help reviewing the common code if that gets impact.

  1.  I didn't mention to have <phase><arch><basename> for the new module. I prefer we just inherit the original module name or file name so we can know the module or the source file has the different implementation for archs in the file browser (when the files are sorted in alphabet).


Lets discuss this using PR if possible.
Thanks
Abner


Below is the draft of principles:

Preface:
The principle is mainly for UefiCpuPKg, but the same principle maybe applied to the EDK2 module that has the processor architecture dependence (such as the BaseLib under MdePkg/Library). Most of the EDK2 modules under UefiCpuPkg were developed specifically to IA32/X64 architecture, that is necessary to reconstruct the folder or revise the source files to accommodate other processor architectures. The EDK2 module reconstruction is also required for accommodating the same-arch-but-different-vendor's implementation (e.g., Intel and AMD for the X86 based processors). The EDK2 module may be strictly developed based on the specific processor architecture. The new introduced implementation for other processor architectures may consider to have a separate EDK2 module instance. Not all of the EDK2 modules revising can exactly meet the principles listed below, that depends on the delta between the original EDK2 module and the implementation for the new introduced processor architecture. It may require the further discussions with EDK2 module maintainers.

The [Arch] refers to the Processor Architecture.
The [Module] refer to the EDK2 module.
The [X86] refers to both IA32 and X64.

The principles to create the X86 folder in the module:

  1.  When X86-vendor's implementation is introduced to the existing module:

  1.  The folder reconstruction:
A-1. If the module is obviously used by IA32/X64 only

  *   No need to create X86 folder
  *   Create X86-vendor's stuff under the root directory of module
A-2. If the existing module is expected to accommodate the different archs or the module already has multiple archs:

  *   Create X86 folder
  *   Create X86-vendor's stuff under X86 folder


  1.  The files reconstruction:
B-1. The module INF metafile

  *   The existing INF metafile should be kept without relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.

     *   <OriginalFileName><arch>.inf


                     B-2. Source files
                              The new arch implementation is introduced to the module in order to leverage the source code and the module design architecture, so

  *   That is contributor's responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific and arch-specific-feature wordings in the file name. Create a common file for the common implementation otherwise.

     *   The file naming for the arch-specific file

<OriginalFileName ><arch>.*

     *   The file naming for the common implementation

< OriginalFileNaming >Common.*

  *   That is contributor's responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor's responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module


  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
  *   Create the arch folder for the new introduced arch



  1.  The files reconstruction:

B-1. The module INF metafile

  *   The existing INF file should be kept without the relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.

     *   < OriginalFileNaming><arch>.inf



B-2. Source files
                             The new arch implementation is introduced to this module in order to leverage the source code and the module design architecture, so

  *   That is contributor's responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific wording in the file name. Create a common file for the common implementation otherwise.

     *   The file naming for the arch-specific source file

< OriginalFileNaming ><arch>.*

     *   The file naming for the common implementation

<OriginalFileNaming>Common.*

  *   That is contributor's responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor's responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module



  1.  When a new arch implementation has a huge delta with the original implementation

Create a separate module instance. The naming of the module should follow below format,

  *   Add the arch prefix with the original module name:

< OriginalModuleNaming><arch>



[-- Attachment #2: Type: text/html, Size: 48353 bytes --]

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

[Michael D Kinney]

[-- Attachment #1: Type: text/plain, Size: 16852 bytes --]

As far as where this type documentation can go there are a couple options.


  1.  The EDK II C Coding Standard Specification does provide some rules for directory names and file names.
  2.  We could add a EDKII Wiki page that covers this topic
  3.  If we want a new published document, we have the tianocore-docs org with support for GitBook syntax documents.

Mike


From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Chang, Abner via groups.io
Sent: Monday, September 26, 2022 12:34 AM
To: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io
Cc: Ni, Ray <ray.ni@intel.com>; Sunil V L <sunilvl@ventanamicro.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]

Thanks for the reply Mike,
>>> I think it would be good to clarify when a difference in implementation is due to a CPU Arch difference or a Vendor implementation difference.
Right, we can have a paragraph to clarify the difference of CPU Arch or a vendor implementation of the same CPU Arch.

If the difference of CPU Arch or a vendor implementation triggers the module reconstruction; and it is a new module or the delta is huge to share the same module, then the file/module name should follow the naming rule you listed above.
It the difference could be added to the existing module, then I think we just keep the existing naming of the file/module to prevent from introducing the impacts on the existing platform or projects meta files.

>>>I am not sure if we should use “Common” in the naming conventions.  I think by default, any content that is not CpuArch or Vendor specific could be considered common content.
Yes agree. The existing file could be a common file if there is no CpuArch or Vendor tag in the file/module name. However, there would be four scenarios,

  1.  CpuArch or vendor specific tag in the existing module/file name and some of the code could be leverage by other arch/vendor:

Strip away the share code and put it into new file and name it without arch/vendor tag. We don’t need “common” in the file name.

  1.  No CpuArch or vendor specific tag in the existing module/file name and some of the code could be leverage by other arch/vendor:

Strip away the arch/vendor specific code and put it into new file named with arch/vendor tag.

  1.  No CpuArch or vendor specific tag in the existing module/file name and the code can be fully leveraged.

Keep it without any change on file/module name.

  1.  If the existing file has the “Common” tag, then just keep it as it.

How is it?

I will revise the doc. I don’t see the good place to create this doc and PR for the review online. I would just create a markdown file under tianocore.github.io/docs just for the temporary. Any other suggestions?

Thanks
Abner



From: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Sent: Saturday, September 24, 2022 2:01 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Leif Lindholm <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
Subject: RE: 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,

I think it would be good to clarify when a difference in implementation is due to a CPU Arch difference or a Vendor implementation difference.

I would also be good to provide guidelines for directory names and file names for all EDK II meta data file types.  Here are some examples to get started:

Package Directory Name:                          <PackageName>Pkg
Package DEC File Name:                                            <PackageName>Pkg.dec

             <PackageName>              REQUIRED           *

Module Directory Name:                           <ModuleName><Phase>
                                                                         < Feature >/<Phase>
Module INF File Name:                              <ModuleName><Phase>.inf
                                                                         < Feature>/<Phase>/<ModuleName>.inf

             <Feature>                           OPTIONAL           Only used if implementation does not have any shared code between phases (e.g. MdeModulePkg/Universal/PCD)
             <Phase>                              REQUIRED           Base, Sec, Pei, Dxe, DxeRuntime, Mm, StandaloneMm, Smm, Uefi
             <ModuleName>                REQUIRED           *

Library Instance Directory Name:             <Phase><CpuArch><Vendor><LibraryClassName><Dependency>
Library Instance INF File Name:              <Phase><CpuArch><Vendor><LibraryClassName><Dependency>.inf

             <Phase>                              REQUIRED           Base, Sec, Pei, Dxe, DxeRuntime, Mm, StandaloneMm, Smm, Uefi
             <CpuArch>                         OPTIONAL           Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc                                        If not provided, then component supports >=2 or all CPU archs
             <Vendor>                           OPTIONAL           *
             <LibraryClassName>        REQUIRED           *
             <Dependency>                  OPTIONAL           *             Typically name of PPI, Protocol, LibraryClass that the implementation is layered on top of.

Source File Paths within a Library/Module instance
             <FileName>.c
             <FileName>.h
             <CpuArch>/<FileName>.c
             <CpuArch>/<FileName>.h
             <CpuArch>/<FileName>.nasm
             <CpuArch>/<FileName>.S

             <CpuArch>                         OPTIONAL           Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc

I think the point you are raising in the discussion is that sometimes there may be shared content between a small subset of CPU archs (e.g. IA32/X64 or Arm/AArch64 or RiscV32/RiscV64/RiscV128) and that you are proposing a new standard directory name for these combinations.  Your proposal is X86 for a directory that contains content for both IA32 and X64.  You are also wanting to support vendor specific content in the naming convention.  An example where it is already being done is in MdePkg/Include/Registers/<VendorName>.   So an enhancement to the above Source File Paths would be:

Source File Paths within a Library/Module instance
             <FileName>.c
             <FileName>.h
             <CpuArch>/<FileName>.c
             <CpuArch>/<FileName>.h
             <CpuArch>/<FileName>.nasm
             <CpuArch>/<FileName>.S
             <CpuArch>/<Vendor>/<FileName>.c
             <CpuArch>/<Vendor>/<FileName>.h
             <CpuArch>/<Vendor>/<FileName>.nasm
             <CpuArch>/<Vendor>/<FileName>.S

             <CpuArch>                         OPTIONAL           Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc, X86
             <Vendor>                           OPTIONAL           *

I am not sure if we should use “Common” in the naming conventions.  I think by default, any content that is not CpuArch or Vendor specific could be considered common content.

Thanks,

Mike

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Chang, Abner via groups.io
Sent: Friday, September 23, 2022 8:39 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Leif Lindholm <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
Subject: [edk2-devel] The principles of EDK2 module reconstruction for archs


[AMD Official Use Only - General]

All,
Today in edk2 open design meeting, we went through the draft of principles of the EDK2 module reconstruction for accommodating different archs (IA32, X64, Arm, AArch64, RiscV64, Loongson64 and etc.) or different vendors of the same arch (AMD/Intel to IA32 and X64).

@Ray Ni<mailto:ray.ni@intel.com> and @michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>

  1.  We may need somewhere on edk2 repo or another place that can have PR for the easy review, please let me know where I can create the PR instead of reviewing this through dev mailing list.
  2.  I didn’t mention using CPUID, Family ID or PCD to have the different code path for AMD and Intel. The reason is,

     *   This decreases the readability of code.
     *   That makes a confusing to the review process

                                                                  i.      Says the maintainer/reviewer owns the package, however the patch is specific to AMD implementation but the change is in the file that mixes up Intel and AMD code. Then who is supposed the right person to give the reviewed-by? Perhaps the AMD edk2 module maintainers or reviewers is the proper person to give the reviewed-by for this case. Of course, other maintainers still can join the review process and give the comments. So to separate the arch-specific code in a arch-specific source file simplifies the review, even that is just a small delta between two implementations.

                                                                ii.      We can have the maintainers or reviewers for the entire module or *Amd* files only. So the maintainers/reviewers do not have to review the changes that only made for other archs. But they have to help reviewing the common code if that gets impact.

  1.  I didn’t mention to have <phase><arch><basename> for the new module. I prefer we just inherit the original module name or file name so we can know the module or the source file has the different implementation for archs in the file browser (when the files are sorted in alphabet).


Lets discuss this using PR if possible.
Thanks
Abner


Below is the draft of principles:

Preface:
The principle is mainly for UefiCpuPKg, but the same principle maybe applied to the EDK2 module that has the processor architecture dependence (such as the BaseLib under MdePkg/Library). Most of the EDK2 modules under UefiCpuPkg were developed specifically to IA32/X64 architecture, that is necessary to reconstruct the folder or revise the source files to accommodate other processor architectures. The EDK2 module reconstruction is also required for accommodating the same-arch-but-different-vendor’s implementation (e.g., Intel and AMD for the X86 based processors). The EDK2 module may be strictly developed based on the specific processor architecture. The new introduced implementation for other processor architectures may consider to have a separate EDK2 module instance. Not all of the EDK2 modules revising can exactly meet the principles listed below, that depends on the delta between the original EDK2 module and the implementation for the new introduced processor architecture. It may require the further discussions with EDK2 module maintainers.

The [Arch] refers to the Processor Architecture.
The [Module] refer to the EDK2 module.
The [X86] refers to both IA32 and X64.

The principles to create the X86 folder in the module:

  1.  When X86-vendor’s implementation is introduced to the existing module:

  1.  The folder reconstruction:
A-1. If the module is obviously used by IA32/X64 only

  *   No need to create X86 folder
  *   Create X86-vendor’s stuff under the root directory of module
A-2. If the existing module is expected to accommodate the different archs or the module already has multiple archs:

  *   Create X86 folder
  *   Create X86-vendor’s stuff under X86 folder


  1.  The files reconstruction:
B-1. The module INF metafile

  *   The existing INF metafile should be kept without relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.

     *   <OriginalFileName><arch>.inf


                     B-2. Source files
                              The new arch implementation is introduced to the module in order to leverage the source code and the module design architecture, so

  *   That is contributor’s responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific and arch-specific-feature wordings in the file name. Create a common file for the common implementation otherwise.

     *   The file naming for the arch-specific file

<OriginalFileName ><arch>.*

     *   The file naming for the common implementation

< OriginalFileNaming >Common.*

  *   That is contributor’s responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor’s responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module


  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
  *   Create the arch folder for the new introduced arch



  1.  The files reconstruction:

B-1. The module INF metafile

  *   The existing INF file should be kept without the relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.

     *   < OriginalFileNaming><arch>.inf



B-2. Source files
                             The new arch implementation is introduced to this module in order to leverage the source code and the module design architecture, so

  *   That is contributor’s responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific wording in the file name. Create a common file for the common implementation otherwise.

     *   The file naming for the arch-specific source file

< OriginalFileNaming ><arch>.*

     *   The file naming for the common implementation

<OriginalFileNaming>Common.*

  *   That is contributor’s responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor’s responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module



  1.  When a new arch implementation has a huge delta with the original implementation

Create a separate module instance. The naming of the module should follow below format,

  *   Add the arch prefix with the original module name:

< OriginalModuleNaming><arch>



[-- Attachment #2: Type: text/html, Size: 93764 bytes --]

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

[Chang, Abner]

[-- Attachment #1: Type: text/plain, Size: 18576 bytes --]

[AMD Official Use Only - General]

Mike how about we take this way,

  *   Add a section in EDK II C Coding standard spec for the module naming rule (you listed above). The naming rule covers the modules under edk2 and edk2-platforms.
  *   Add a EDKII Wiki page for "The Principles of EDK2 Module Reconstruction for the Processor Architecture"

Refer to the Module Naming Rule section in "EDK II C Coding standard spec" for the module reconstruction mentioned in "The Principles of EDK2 Module Reconstruction for the Processor Architecture" doc.
Abner

From: Kinney, Michael D <michael.d.kinney@intel.com>
Sent: Monday, September 26, 2022 11:45 PM
To: devel@edk2.groups.io; Chang, Abner <Abner.Chang@amd.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Ni, Ray <ray.ni@intel.com>; Sunil V L <sunilvl@ventanamicro.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>; Kinney, Michael D <michael.d.kinney@intel.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.

As far as where this type documentation can go there are a couple options.


  1.  The EDK II C Coding Standard Specification does provide some rules for directory names and file names.
  2.  We could add a EDKII Wiki page that covers this topic
  3.  If we want a new published document, we have the tianocore-docs org with support for GitBook syntax documents.

Mike


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


[AMD Official Use Only - General]

Thanks for the reply Mike,
>>> I think it would be good to clarify when a difference in implementation is due to a CPU Arch difference or a Vendor implementation difference.
Right, we can have a paragraph to clarify the difference of CPU Arch or a vendor implementation of the same CPU Arch.

If the difference of CPU Arch or a vendor implementation triggers the module reconstruction; and it is a new module or the delta is huge to share the same module, then the file/module name should follow the naming rule you listed above.
It the difference could be added to the existing module, then I think we just keep the existing naming of the file/module to prevent from introducing the impacts on the existing platform or projects meta files.

>>>I am not sure if we should use "Common" in the naming conventions.  I think by default, any content that is not CpuArch or Vendor specific could be considered common content.
Yes agree. The existing file could be a common file if there is no CpuArch or Vendor tag in the file/module name. However, there would be four scenarios,

  1.  CpuArch or vendor specific tag in the existing module/file name and some of the code could be leverage by other arch/vendor:

Strip away the share code and put it into new file and name it without arch/vendor tag. We don't need "common" in the file name.

  1.  No CpuArch or vendor specific tag in the existing module/file name and some of the code could be leverage by other arch/vendor:

Strip away the arch/vendor specific code and put it into new file named with arch/vendor tag.

  1.  No CpuArch or vendor specific tag in the existing module/file name and the code can be fully leveraged.

Keep it without any change on file/module name.

  1.  If the existing file has the "Common" tag, then just keep it as it.

How is it?

I will revise the doc. I don't see the good place to create this doc and PR for the review online. I would just create a markdown file under tianocore.github.io/docs just for the temporary. Any other suggestions?

Thanks
Abner



From: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Sent: Saturday, September 24, 2022 2:01 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Leif Lindholm <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
Subject: RE: 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,

I think it would be good to clarify when a difference in implementation is due to a CPU Arch difference or a Vendor implementation difference.

I would also be good to provide guidelines for directory names and file names for all EDK II meta data file types.  Here are some examples to get started:

Package Directory Name:                          <PackageName>Pkg
Package DEC File Name:                                            <PackageName>Pkg.dec

             <PackageName>              REQUIRED           *

Module Directory Name:                           <ModuleName><Phase>
                                                                         < Feature >/<Phase>
Module INF File Name:                              <ModuleName><Phase>.inf
                                                                         < Feature>/<Phase>/<ModuleName>.inf

             <Feature>                           OPTIONAL           Only used if implementation does not have any shared code between phases (e.g. MdeModulePkg/Universal/PCD)
             <Phase>                              REQUIRED           Base, Sec, Pei, Dxe, DxeRuntime, Mm, StandaloneMm, Smm, Uefi
             <ModuleName>                REQUIRED           *

Library Instance Directory Name:             <Phase><CpuArch><Vendor><LibraryClassName><Dependency>
Library Instance INF File Name:              <Phase><CpuArch><Vendor><LibraryClassName><Dependency>.inf

             <Phase>                              REQUIRED           Base, Sec, Pei, Dxe, DxeRuntime, Mm, StandaloneMm, Smm, Uefi
             <CpuArch>                         OPTIONAL           Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc                                        If not provided, then component supports >=2 or all CPU archs
             <Vendor>                           OPTIONAL           *
             <LibraryClassName>        REQUIRED           *
             <Dependency>                  OPTIONAL           *             Typically name of PPI, Protocol, LibraryClass that the implementation is layered on top of.

Source File Paths within a Library/Module instance
             <FileName>.c
             <FileName>.h
             <CpuArch>/<FileName>.c
             <CpuArch>/<FileName>.h
             <CpuArch>/<FileName>.nasm
             <CpuArch>/<FileName>.S

             <CpuArch>                         OPTIONAL           Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc

I think the point you are raising in the discussion is that sometimes there may be shared content between a small subset of CPU archs (e.g. IA32/X64 or Arm/AArch64 or RiscV32/RiscV64/RiscV128) and that you are proposing a new standard directory name for these combinations.  Your proposal is X86 for a directory that contains content for both IA32 and X64.  You are also wanting to support vendor specific content in the naming convention.  An example where it is already being done is in MdePkg/Include/Registers/<VendorName>.   So an enhancement to the above Source File Paths would be:

Source File Paths within a Library/Module instance
             <FileName>.c
             <FileName>.h
             <CpuArch>/<FileName>.c
             <CpuArch>/<FileName>.h
             <CpuArch>/<FileName>.nasm
             <CpuArch>/<FileName>.S
             <CpuArch>/<Vendor>/<FileName>.c
             <CpuArch>/<Vendor>/<FileName>.h
             <CpuArch>/<Vendor>/<FileName>.nasm
             <CpuArch>/<Vendor>/<FileName>.S

             <CpuArch>                         OPTIONAL           Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc, X86
             <Vendor>                           OPTIONAL           *

I am not sure if we should use "Common" in the naming conventions.  I think by default, any content that is not CpuArch or Vendor specific could be considered common content.

Thanks,

Mike

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Chang, Abner via groups.io
Sent: Friday, September 23, 2022 8:39 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Leif Lindholm <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
Subject: [edk2-devel] The principles of EDK2 module reconstruction for archs


[AMD Official Use Only - General]

All,
Today in edk2 open design meeting, we went through the draft of principles of the EDK2 module reconstruction for accommodating different archs (IA32, X64, Arm, AArch64, RiscV64, Loongson64 and etc.) or different vendors of the same arch (AMD/Intel to IA32 and X64).

@Ray Ni<mailto:ray.ni@intel.com> and @michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>

  1.  We may need somewhere on edk2 repo or another place that can have PR for the easy review, please let me know where I can create the PR instead of reviewing this through dev mailing list.
  2.  I didn't mention using CPUID, Family ID or PCD to have the different code path for AMD and Intel. The reason is,

     *   This decreases the readability of code.
     *   That makes a confusing to the review process

                                                          i.     Says the maintainer/reviewer owns the package, however the patch is specific to AMD implementation but the change is in the file that mixes up Intel and AMD code. Then who is supposed the right person to give the reviewed-by? Perhaps the AMD edk2 module maintainers or reviewers is the proper person to give the reviewed-by for this case. Of course, other maintainers still can join the review process and give the comments. So to separate the arch-specific code in a arch-specific source file simplifies the review, even that is just a small delta between two implementations.

                                                        ii.     We can have the maintainers or reviewers for the entire module or *Amd* files only. So the maintainers/reviewers do not have to review the changes that only made for other archs. But they have to help reviewing the common code if that gets impact.

  1.  I didn't mention to have <phase><arch><basename> for the new module. I prefer we just inherit the original module name or file name so we can know the module or the source file has the different implementation for archs in the file browser (when the files are sorted in alphabet).


Lets discuss this using PR if possible.
Thanks
Abner


Below is the draft of principles:

Preface:
The principle is mainly for UefiCpuPKg, but the same principle maybe applied to the EDK2 module that has the processor architecture dependence (such as the BaseLib under MdePkg/Library). Most of the EDK2 modules under UefiCpuPkg were developed specifically to IA32/X64 architecture, that is necessary to reconstruct the folder or revise the source files to accommodate other processor architectures. The EDK2 module reconstruction is also required for accommodating the same-arch-but-different-vendor's implementation (e.g., Intel and AMD for the X86 based processors). The EDK2 module may be strictly developed based on the specific processor architecture. The new introduced implementation for other processor architectures may consider to have a separate EDK2 module instance. Not all of the EDK2 modules revising can exactly meet the principles listed below, that depends on the delta between the original EDK2 module and the implementation for the new introduced processor architecture. It may require the further discussions with EDK2 module maintainers.

The [Arch] refers to the Processor Architecture.
The [Module] refer to the EDK2 module.
The [X86] refers to both IA32 and X64.

The principles to create the X86 folder in the module:

  1.  When X86-vendor's implementation is introduced to the existing module:

  1.  The folder reconstruction:
A-1. If the module is obviously used by IA32/X64 only

  *   No need to create X86 folder
  *   Create X86-vendor's stuff under the root directory of module
A-2. If the existing module is expected to accommodate the different archs or the module already has multiple archs:

  *   Create X86 folder
  *   Create X86-vendor's stuff under X86 folder


  1.  The files reconstruction:
B-1. The module INF metafile

  *   The existing INF metafile should be kept without relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.

     *   <OriginalFileName><arch>.inf


                     B-2. Source files
                              The new arch implementation is introduced to the module in order to leverage the source code and the module design architecture, so

  *   That is contributor's responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific and arch-specific-feature wordings in the file name. Create a common file for the common implementation otherwise.

     *   The file naming for the arch-specific file

<OriginalFileName ><arch>.*

     *   The file naming for the common implementation

< OriginalFileNaming >Common.*

  *   That is contributor's responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor's responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module


  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
  *   Create the arch folder for the new introduced arch



  1.  The files reconstruction:

B-1. The module INF metafile

  *   The existing INF file should be kept without the relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.

     *   < OriginalFileNaming><arch>.inf



B-2. Source files
                             The new arch implementation is introduced to this module in order to leverage the source code and the module design architecture, so

  *   That is contributor's responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific wording in the file name. Create a common file for the common implementation otherwise.

     *   The file naming for the arch-specific source file

< OriginalFileNaming ><arch>.*

     *   The file naming for the common implementation

<OriginalFileNaming>Common.*

  *   That is contributor's responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor's responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module



  1.  When a new arch implementation has a huge delta with the original implementation

Create a separate module instance. The naming of the module should follow below format,

  *   Add the arch prefix with the original module name:

< OriginalModuleNaming><arch>



[-- Attachment #2: Type: text/html, Size: 57818 bytes --]

Re: The principles of EDK2 module reconstruction for archs

[Ni, Ray]

[-- Attachment #1: Type: text/plain, Size: 5441 bytes --]

The [Arch] refers to the Processor Architecture.
The [Module] refer to the EDK2 module.
The [X86] refers to both IA32 and X64.
The principles to create the X86 folder in the module:

  1.  When X86-vendor's implementation is introduced to the existing module:

  1.  The folder reconstruction:
A-1. If the module is obviously used by IA32/X64 only

  *   No need to create X86 folder
  *   Create X86-vendor's stuff under the root directory of module
A-2. If the existing module is expected to accommodate the different archs or the module already has multiple archs:

  *   Create X86 folder
  *   Create X86-vendor's stuff under X86 folder
[Ray] Looks good.


  1.  The files reconstruction:
B-1. The module INF metafile

  *   The existing INF metafile should be kept without relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.
     *   <OriginalFileName><arch>.inf
[Ray]  "CpuDxe.inf" and "CpuDxeArm.inf"? is that your intention? New developers may be confused that CpuDxe.inf supports only X86 arch.
Do you have an example that one module supporting multiple archs using different INF files? MdeModulePkg/DxeIpl is a module supporting different archs with the same INF file.
Or shall we leave it to be decided between the patch contributor and package/module maintainer?


                     B-2. Source files
                              The new arch implementation is introduced to the module in order to leverage the source code and the module design architecture, so

  *   That is contributor's responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific and arch-specific-feature wordings in the file name. Create a common file for the common implementation otherwise.
     *   The file naming for the arch-specific file

<OriginalFileName ><arch>.*

     *   The file naming for the common implementation

< OriginalFileNaming >Common.*

  *   That is contributor's responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor's responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module
[Ray] If you check the MpInitLib, most of SEV logic are moved to AmdSev.c. But MpLib.c still contains logic to call functions from AmdSev.c based on some AMD specific check. In my opinion, that's already good enough.
However, if you check MdeModulePkg/DxeIpl, implementations for different archs are in different *folders*.
Can we leave this to the module owner to decide how to place the implementations?



  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.


  1.  The files reconstruction:

B-1. The module INF metafile

  *   The existing INF file should be kept without the relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.
     *   < OriginalFileNaming><arch>.inf



B-2. Source files
                             The new arch implementation is introduced to this module in order to leverage the source code and the module design architecture, so

  *   That is contributor's responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific wording in the file name. Create a common file for the common implementation otherwise.
     *   The file naming for the arch-specific source file

< OriginalFileNaming ><arch>.*

     *   The file naming for the common implementation

<OriginalFileNaming>Common.*

  *   That is contributor's responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor's responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module



  1.  When a new arch implementation has a huge delta with the original implementation

Create a separate module instance. The naming of the module should follow below format,

  *   Add the arch prefix with the original module name:

< OriginalModuleNaming><arch>



[-- Attachment #2: Type: text/html, Size: 22833 bytes --]

Re: The principles of EDK2 module reconstruction for archs

[Ni, Ray]

[-- Attachment #1: Type: text/plain, Size: 13700 bytes --]

Mike,
Has following content already been documented somewhere?
It looks good to me. Very good abstraction of existing cases. Maybe there are some lib/modules that don’t follow this rule. But the number should be very small.

But I didn’t check how ARM constructs the pkg. So it’s very welcomed to see non-X86 people for review.

Thanks,
Ray

From: Kinney, Michael D <michael.d.kinney@intel.com>
Sent: Saturday, September 24, 2022 2:01 AM
To: devel@edk2.groups.io; abner.chang@amd.com; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Ni, Ray <ray.ni@intel.com>; Sunil V L <sunilvl@ventanamicro.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: The principles of EDK2 module reconstruction for archs

Hi Abner,

I think it would be good to clarify when a difference in implementation is due to a CPU Arch difference or a Vendor implementation difference.

I would also be good to provide guidelines for directory names and file names for all EDK II meta data file types.  Here are some examples to get started:

Package Directory Name:                           <PackageName>Pkg
Package DEC File Name:                                             <PackageName>Pkg.dec

              <PackageName>              REQUIRED           *

Module Directory Name:                            <ModuleName><Phase>
                                                                              < Feature >/<Phase>
Module INF File Name:                                <ModuleName><Phase>.inf
                                                                              < Feature>/<Phase>/<ModuleName>.inf

              <Feature>                           OPTIONAL           Only used if implementation does not have any shared code between phases (e.g. MdeModulePkg/Universal/PCD)
              <Phase>                              REQUIRED           Base, Sec, Pei, Dxe, DxeRuntime, Mm, StandaloneMm, Smm, Uefi
              <ModuleName>               REQUIRED           *

[Ray] Looks good to me. Good abstraction of existing cases.

Library Instance Directory Name:            <Phase><CpuArch><Vendor><LibraryClassName><Dependency>
Library Instance INF File Name:                               <Phase><CpuArch><Vendor><LibraryClassName><Dependency>.inf

              <Phase>                              REQUIRED           Base, Sec, Pei, Dxe, DxeRuntime, Mm, StandaloneMm, Smm, Uefi
              <CpuArch>                         OPTIONAL           Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc                                      If not provided, then component supports >=2 or all CPU archs
              <Vendor>                           OPTIONAL           *
              <LibraryClassName>       REQUIRED           *
              <Dependency>                 OPTIONAL           *             Typically name of PPI, Protocol, LibraryClass that the implementation is layered on top of.

Source File Paths within a Library/Module instance
              <FileName>.c
              <FileName>.h
              <CpuArch>/<FileName>.c
              <CpuArch>/<FileName>.h
              <CpuArch>/<FileName>.nasm
              <CpuArch>/<FileName>.S

              <CpuArch>                         OPTIONAL           Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc
[Ray] Looks good to me. Good abstraction of existing cases.


I think the point you are raising in the discussion is that sometimes there may be shared content between a small subset of CPU archs (e.g. IA32/X64 or Arm/AArch64 or RiscV32/RiscV64/RiscV128) and that you are proposing a new standard directory name for these combinations.  Your proposal is X86 for a directory that contains content for both IA32 and X64.  You are also wanting to support vendor specific content in the naming convention.  An example where it is already being done is in MdePkg/Include/Registers/<VendorName>.   So an enhancement to the above Source File Paths would be:

Source File Paths within a Library/Module instance
              <FileName>.c
              <FileName>.h
              <CpuArch>/<FileName>.c
              <CpuArch>/<FileName>.h
              <CpuArch>/<FileName>.nasm
              <CpuArch>/<FileName>.S
              <CpuArch>/<Vendor>/<FileName>.c
              <CpuArch>/<Vendor>/<FileName>.h
              <CpuArch>/<Vendor>/<FileName>.nasm
              <CpuArch>/<Vendor>/<FileName>.S

              <CpuArch>                         OPTIONAL           Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc, X86
              <Vendor>                           OPTIONAL           *

I am not sure if we should use “Common” in the naming conventions.  I think by default, any content that is not CpuArch or Vendor specific could be considered common content.

[Ray] Good to me.

Thanks,

Mike

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Chang, Abner via groups.io
Sent: Friday, September 23, 2022 8:39 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Leif Lindholm <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
Subject: [edk2-devel] The principles of EDK2 module reconstruction for archs


[AMD Official Use Only - General]

All,
Today in edk2 open design meeting, we went through the draft of principles of the EDK2 module reconstruction for accommodating different archs (IA32, X64, Arm, AArch64, RiscV64, Loongson64 and etc.) or different vendors of the same arch (AMD/Intel to IA32 and X64).

@Ray Ni<mailto:ray.ni@intel.com> and @michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>

  1.  We may need somewhere on edk2 repo or another place that can have PR for the easy review, please let me know where I can create the PR instead of reviewing this through dev mailing list.
  2.  I didn’t mention using CPUID, Family ID or PCD to have the different code path for AMD and Intel. The reason is,

     *   This decreases the readability of code.
     *   That makes a confusing to the review process

                                                                  i.      Says the maintainer/reviewer owns the package, however the patch is specific to AMD implementation but the change is in the file that mixes up Intel and AMD code. Then who is supposed the right person to give the reviewed-by? Perhaps the AMD edk2 module maintainers or reviewers is the proper person to give the reviewed-by for this case. Of course, other maintainers still can join the review process and give the comments. So to separate the arch-specific code in a arch-specific source file simplifies the review, even that is just a small delta between two implementations.

                                                                ii.      We can have the maintainers or reviewers for the entire module or *Amd* files only. So the maintainers/reviewers do not have to review the changes that only made for other archs. But they have to help reviewing the common code if that gets impact.

  1.  I didn’t mention to have <phase><arch><basename> for the new module. I prefer we just inherit the original module name or file name so we can know the module or the source file has the different implementation for archs in the file browser (when the files are sorted in alphabet).


Lets discuss this using PR if possible.
Thanks
Abner


Below is the draft of principles:

Preface:
The principle is mainly for UefiCpuPKg, but the same principle maybe applied to the EDK2 module that has the processor architecture dependence (such as the BaseLib under MdePkg/Library). Most of the EDK2 modules under UefiCpuPkg were developed specifically to IA32/X64 architecture, that is necessary to reconstruct the folder or revise the source files to accommodate other processor architectures. The EDK2 module reconstruction is also required for accommodating the same-arch-but-different-vendor’s implementation (e.g., Intel and AMD for the X86 based processors). The EDK2 module may be strictly developed based on the specific processor architecture. The new introduced implementation for other processor architectures may consider to have a separate EDK2 module instance. Not all of the EDK2 modules revising can exactly meet the principles listed below, that depends on the delta between the original EDK2 module and the implementation for the new introduced processor architecture. It may require the further discussions with EDK2 module maintainers.

The [Arch] refers to the Processor Architecture.
The [Module] refer to the EDK2 module.
The [X86] refers to both IA32 and X64.

The principles to create the X86 folder in the module:

  1.  When X86-vendor’s implementation is introduced to the existing module:

  1.  The folder reconstruction:
A-1. If the module is obviously used by IA32/X64 only

  *   No need to create X86 folder
  *   Create X86-vendor’s stuff under the root directory of module
A-2. If the existing module is expected to accommodate the different archs or the module already has multiple archs:

  *   Create X86 folder
  *   Create X86-vendor’s stuff under X86 folder


  1.  The files reconstruction:
B-1. The module INF metafile

  *   The existing INF metafile should be kept without relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.

     *   <OriginalFileName><arch>.inf


                     B-2. Source files
                              The new arch implementation is introduced to the module in order to leverage the source code and the module design architecture, so

  *   That is contributor’s responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific and arch-specific-feature wordings in the file name. Create a common file for the common implementation otherwise.

     *   The file naming for the arch-specific file

<OriginalFileName ><arch>.*

     *   The file naming for the common implementation

< OriginalFileNaming >Common.*

  *   That is contributor’s responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor’s responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module


  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
  *   Create the arch folder for the new introduced arch



  1.  The files reconstruction:

B-1. The module INF metafile

  *   The existing INF file should be kept without the relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.

     *   < OriginalFileNaming><arch>.inf



B-2. Source files
                             The new arch implementation is introduced to this module in order to leverage the source code and the module design architecture, so

  *   That is contributor’s responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific wording in the file name. Create a common file for the common implementation otherwise.

     *   The file naming for the arch-specific source file

< OriginalFileNaming ><arch>.*

     *   The file naming for the common implementation

<OriginalFileNaming>Common.*

  *   That is contributor’s responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor’s responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module



  1.  When a new arch implementation has a huge delta with the original implementation

Create a separate module instance. The naming of the module should follow below format,

  *   Add the arch prefix with the original module name:

< OriginalModuleNaming><arch>



[-- Attachment #2: Type: text/html, Size: 44094 bytes --]

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

[Chang, Abner]

[-- Attachment #1: Type: text/plain, Size: 7628 bytes --]

[AMD Official Use Only - General]



From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ni, Ray via groups.io
Sent: Wednesday, September 28, 2022 11:34 AM
To: devel@edk2.groups.io; Chang, Abner <Abner.Chang@amd.com>
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Sunil V L <sunilvl@ventanamicro.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.

The [Arch] refers to the Processor Architecture.
The [Module] refer to the EDK2 module.
The [X86] refers to both IA32 and X64.
The principles to create the X86 folder in the module:

  1.  When X86-vendor's implementation is introduced to the existing module:

  1.  The folder reconstruction:
A-1. If the module is obviously used by IA32/X64 only

  *   No need to create X86 folder
  *   Create X86-vendor's stuff under the root directory of module
A-2. If the existing module is expected to accommodate the different archs or the module already has multiple archs:

  *   Create X86 folder
  *   Create X86-vendor's stuff under X86 folder
[Ray] Looks good.


  1.  The files reconstruction:
B-1. The module INF metafile

  *   The existing INF metafile should be kept without relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.

     *   <OriginalFileName><arch>.inf
[Ray]  "CpuDxe.inf" and "CpuDxeArm.inf"? is that your intention? New developers may be confused that CpuDxe.inf supports only X86 arch.
Do you have an example that one module supporting multiple archs using different INF files? MdeModulePkg/DxeIpl is a module supporting different archs with the same INF file.
Or shall we leave it to be decided between the patch contributor and package/module maintainer?
[Chang, Abner]  Here I mean the library module, for example SmmCpuFeatureLib.inf and AmdSmmCpuFeatureLib.inf. Will make the statement clear. The file naming above would be changed to <arch><OriginalFileName>.inf as Mike suggested.

I am not sure if there is another example having arch-specific INF file. Usually the driver module has the abstract interface and the implementation in the library module. A newly introduced processor architecture driver may create it's own module such as ArmCpuDxe if the delta between implementations  is huge. However, I would prefer to have arch-specific INF for the module if the module implementation can be leveraged. And yes, this requires the discussion between contributor and module maintainer if the principles can not perfectly identify the case.

                     B-2. Source files
                              The new arch implementation is introduced to the module in order to leverage the source code and the module design architecture, so

  *   That is contributor's responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific and arch-specific-feature wordings in the file name. Create a common file for the common implementation otherwise.

     *   The file naming for the arch-specific file

<OriginalFileName ><arch>.*

     *   The file naming for the common implementation

< OriginalFileNaming >Common.*

  *   That is contributor's responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor's responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module
[Ray] If you check the MpInitLib, most of SEV logic are moved to AmdSev.c. But MpLib.c still contains logic to call functions from AmdSev.c based on some AMD specific check. In my opinion, that's already good enough.
[Chang, Abner]  I am not quite lean to the If-AMD-else in the source file solution. I prefer to separate AMD stuff or vendor feature to a separated file. So we can have the reviewer or maintainer for *Amd* files/module/packages specifically. This makes the review responsibility clear and efficient.

However, if you check MdeModulePkg/DxeIpl, implementations for different archs are in different *folders*.
Can we leave this to the module owner to decide how to place the implementations?




  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.
[Chang, Abner] We will move the arch implementation to the arch folder without moving INF. This wont impact the platform DSC and FDF, however this has the impact to the existing overwrite.

  *   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.
[Chang, Abner] right, so the first bullet is important.

[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.


  1.  The files reconstruction:

B-1. The module INF metafile

  *   The existing INF file should be kept without the relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.

     *   < OriginalFileNaming><arch>.inf



B-2. Source files
                             The new arch implementation is introduced to this module in order to leverage the source code and the module design architecture, so

  *   That is contributor's responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific wording in the file name. Create a common file for the common implementation otherwise.

     *   The file naming for the arch-specific source file

< OriginalFileNaming ><arch>.*

     *   The file naming for the common implementation

<OriginalFileNaming>Common.*

  *   That is contributor's responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor's responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module



  1.  When a new arch implementation has a huge delta with the original implementation

Create a separate module instance. The naming of the module should follow below format,

  *   Add the arch prefix with the original module name:

< OriginalModuleNaming><arch>



[-- Attachment #2: Type: text/html, Size: 25779 bytes --]

Re: The principles of EDK2 module reconstruction for archs

[Chang, Abner]

[-- Attachment #1: Type: text/plain, Size: 15187 bytes --]

[AMD Official Use Only - General]

We had the conversation this morning regarding the proper place for the file/module naming rule.
The proposal is the naming rule content would be documented in "edk2 C coding standard spec", and the "The principles of EDK2 module reconstruction for archs" would be on the edk2 Wiki page then refers to the section in "edk2 C coding standard spec" for the naming rule.

Abner

From: Ni, Ray <ray.ni@intel.com>
Sent: Wednesday, September 28, 2022 11:56 AM
To: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io; Chang, Abner <Abner.Chang@amd.com>
Cc: Sunil V L <sunilvl@ventanamicro.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: 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.

Mike,
Has following content already been documented somewhere?
It looks good to me. Very good abstraction of existing cases. Maybe there are some lib/modules that don't follow this rule. But the number should be very small.

But I didn't check how ARM constructs the pkg. So it's very welcomed to see non-X86 people for review.

Thanks,
Ray

From: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Sent: Saturday, September 24, 2022 2:01 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; abner.chang@amd.com<mailto:abner.chang@amd.com>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Leif Lindholm <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
Subject: RE: The principles of EDK2 module reconstruction for archs

Hi Abner,

I think it would be good to clarify when a difference in implementation is due to a CPU Arch difference or a Vendor implementation difference.

I would also be good to provide guidelines for directory names and file names for all EDK II meta data file types.  Here are some examples to get started:

Package Directory Name:                           <PackageName>Pkg
Package DEC File Name:                                             <PackageName>Pkg.dec

              <PackageName>              REQUIRED           *

Module Directory Name:                            <ModuleName><Phase>
                                                                              < Feature >/<Phase>
Module INF File Name:                                <ModuleName><Phase>.inf
                                                                              < Feature>/<Phase>/<ModuleName>.inf

              <Feature>                           OPTIONAL           Only used if implementation does not have any shared code between phases (e.g. MdeModulePkg/Universal/PCD)
              <Phase>                              REQUIRED           Base, Sec, Pei, Dxe, DxeRuntime, Mm, StandaloneMm, Smm, Uefi
              <ModuleName>               REQUIRED           *

[Ray] Looks good to me. Good abstraction of existing cases.

Library Instance Directory Name:            <Phase><CpuArch><Vendor><LibraryClassName><Dependency>
Library Instance INF File Name:                               <Phase><CpuArch><Vendor><LibraryClassName><Dependency>.inf

              <Phase>                              REQUIRED           Base, Sec, Pei, Dxe, DxeRuntime, Mm, StandaloneMm, Smm, Uefi
              <CpuArch>                         OPTIONAL           Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc                                      If not provided, then component supports >=2 or all CPU archs
              <Vendor>                           OPTIONAL           *
              <LibraryClassName>       REQUIRED           *
              <Dependency>                 OPTIONAL           *             Typically name of PPI, Protocol, LibraryClass that the implementation is layered on top of.

Source File Paths within a Library/Module instance
              <FileName>.c
              <FileName>.h
              <CpuArch>/<FileName>.c
              <CpuArch>/<FileName>.h
              <CpuArch>/<FileName>.nasm
              <CpuArch>/<FileName>.S

              <CpuArch>                         OPTIONAL           Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc
[Ray] Looks good to me. Good abstraction of existing cases.


I think the point you are raising in the discussion is that sometimes there may be shared content between a small subset of CPU archs (e.g. IA32/X64 or Arm/AArch64 or RiscV32/RiscV64/RiscV128) and that you are proposing a new standard directory name for these combinations.  Your proposal is X86 for a directory that contains content for both IA32 and X64.  You are also wanting to support vendor specific content in the naming convention.  An example where it is already being done is in MdePkg/Include/Registers/<VendorName>.   So an enhancement to the above Source File Paths would be:

Source File Paths within a Library/Module instance
              <FileName>.c
              <FileName>.h
              <CpuArch>/<FileName>.c
              <CpuArch>/<FileName>.h
              <CpuArch>/<FileName>.nasm
              <CpuArch>/<FileName>.S
              <CpuArch>/<Vendor>/<FileName>.c
              <CpuArch>/<Vendor>/<FileName>.h
              <CpuArch>/<Vendor>/<FileName>.nasm
              <CpuArch>/<Vendor>/<FileName>.S

              <CpuArch>                         OPTIONAL           Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc, X86
              <Vendor>                           OPTIONAL           *

I am not sure if we should use "Common" in the naming conventions.  I think by default, any content that is not CpuArch or Vendor specific could be considered common content.

[Ray] Good to me.

Thanks,

Mike

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Chang, Abner via groups.io
Sent: Friday, September 23, 2022 8:39 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Leif Lindholm <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
Subject: [edk2-devel] The principles of EDK2 module reconstruction for archs


[AMD Official Use Only - General]

All,
Today in edk2 open design meeting, we went through the draft of principles of the EDK2 module reconstruction for accommodating different archs (IA32, X64, Arm, AArch64, RiscV64, Loongson64 and etc.) or different vendors of the same arch (AMD/Intel to IA32 and X64).

@Ray Ni<mailto:ray.ni@intel.com> and @michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>

  1.  We may need somewhere on edk2 repo or another place that can have PR for the easy review, please let me know where I can create the PR instead of reviewing this through dev mailing list.
  2.  I didn't mention using CPUID, Family ID or PCD to have the different code path for AMD and Intel. The reason is,

     *   This decreases the readability of code.
     *   That makes a confusing to the review process

                                                          i.     Says the maintainer/reviewer owns the package, however the patch is specific to AMD implementation but the change is in the file that mixes up Intel and AMD code. Then who is supposed the right person to give the reviewed-by? Perhaps the AMD edk2 module maintainers or reviewers is the proper person to give the reviewed-by for this case. Of course, other maintainers still can join the review process and give the comments. So to separate the arch-specific code in a arch-specific source file simplifies the review, even that is just a small delta between two implementations.

                                                        ii.     We can have the maintainers or reviewers for the entire module or *Amd* files only. So the maintainers/reviewers do not have to review the changes that only made for other archs. But they have to help reviewing the common code if that gets impact.

  1.  I didn't mention to have <phase><arch><basename> for the new module. I prefer we just inherit the original module name or file name so we can know the module or the source file has the different implementation for archs in the file browser (when the files are sorted in alphabet).


Lets discuss this using PR if possible.
Thanks
Abner


Below is the draft of principles:

Preface:
The principle is mainly for UefiCpuPKg, but the same principle maybe applied to the EDK2 module that has the processor architecture dependence (such as the BaseLib under MdePkg/Library). Most of the EDK2 modules under UefiCpuPkg were developed specifically to IA32/X64 architecture, that is necessary to reconstruct the folder or revise the source files to accommodate other processor architectures. The EDK2 module reconstruction is also required for accommodating the same-arch-but-different-vendor's implementation (e.g., Intel and AMD for the X86 based processors). The EDK2 module may be strictly developed based on the specific processor architecture. The new introduced implementation for other processor architectures may consider to have a separate EDK2 module instance. Not all of the EDK2 modules revising can exactly meet the principles listed below, that depends on the delta between the original EDK2 module and the implementation for the new introduced processor architecture. It may require the further discussions with EDK2 module maintainers.

The [Arch] refers to the Processor Architecture.
The [Module] refer to the EDK2 module.
The [X86] refers to both IA32 and X64.

The principles to create the X86 folder in the module:

  1.  When X86-vendor's implementation is introduced to the existing module:

  1.  The folder reconstruction:
A-1. If the module is obviously used by IA32/X64 only

  *   No need to create X86 folder
  *   Create X86-vendor's stuff under the root directory of module
A-2. If the existing module is expected to accommodate the different archs or the module already has multiple archs:

  *   Create X86 folder
  *   Create X86-vendor's stuff under X86 folder


  1.  The files reconstruction:
B-1. The module INF metafile

  *   The existing INF metafile should be kept without relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.

     *   <OriginalFileName><arch>.inf


                     B-2. Source files
                              The new arch implementation is introduced to the module in order to leverage the source code and the module design architecture, so

  *   That is contributor's responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific and arch-specific-feature wordings in the file name. Create a common file for the common implementation otherwise.

     *   The file naming for the arch-specific file

<OriginalFileName ><arch>.*

     *   The file naming for the common implementation

< OriginalFileNaming >Common.*

  *   That is contributor's responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor's responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module


  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
  *   Create the arch folder for the new introduced arch



  1.  The files reconstruction:

B-1. The module INF metafile

  *   The existing INF file should be kept without the relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.

     *   < OriginalFileNaming><arch>.inf



B-2. Source files
                             The new arch implementation is introduced to this module in order to leverage the source code and the module design architecture, so

  *   That is contributor's responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific wording in the file name. Create a common file for the common implementation otherwise.

     *   The file naming for the arch-specific source file

< OriginalFileNaming ><arch>.*

     *   The file naming for the common implementation

<OriginalFileNaming>Common.*

  *   That is contributor's responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor's responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module



  1.  When a new arch implementation has a huge delta with the original implementation

Create a separate module instance. The naming of the module should follow below format,

  *   Add the arch prefix with the original module name:

< OriginalModuleNaming><arch>



[-- Attachment #2: Type: text/html, Size: 47170 bytes --]

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

[Ni, Ray]

[-- Attachment #1: Type: text/plain, Size: 9750 bytes --]

Abner,
I think we Mike’s first email regarding the package structure is a good guideline regarding how to place the modules.

What we are discussing is how to organize the module internal contents for different archs. Do you agree?
I want to clarify this so we have a clear boundary between the two topics.

However, Mike’s proposal also defines the <arch> folder inside a module directory.
Maybe we just work together to refine Mike’s proposal and document it in EDKII coding standard document.

Chao, can you check Mike’s proposal and raise if there is anything not captured?

Thanks,
Ray

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Chang, Abner via groups.io
Sent: Wednesday, September 28, 2022 12:31 PM
To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Sunil V L <sunilvl@ventanamicro.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]



From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Ni, Ray via groups.io
Sent: Wednesday, September 28, 2022 11:34 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>
Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Leif Lindholm <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish <afish@apple.com<mailto: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.

The [Arch] refers to the Processor Architecture.
The [Module] refer to the EDK2 module.
The [X86] refers to both IA32 and X64.
The principles to create the X86 folder in the module:

  1.  When X86-vendor’s implementation is introduced to the existing module:

  1.  The folder reconstruction:
A-1. If the module is obviously used by IA32/X64 only

  *   No need to create X86 folder
  *   Create X86-vendor’s stuff under the root directory of module
A-2. If the existing module is expected to accommodate the different archs or the module already has multiple archs:

  *   Create X86 folder
  *   Create X86-vendor’s stuff under X86 folder
[Ray] Looks good.


  1.  The files reconstruction:
B-1. The module INF metafile

  *   The existing INF metafile should be kept without relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.

     *   <OriginalFileName><arch>.inf
[Ray]  “CpuDxe.inf” and “CpuDxeArm.inf”? is that your intention? New developers may be confused that CpuDxe.inf supports only X86 arch.
Do you have an example that one module supporting multiple archs using different INF files? MdeModulePkg/DxeIpl is a module supporting different archs with the same INF file.
Or shall we leave it to be decided between the patch contributor and package/module maintainer?
[Chang, Abner]  Here I mean the library module, for example SmmCpuFeatureLib.inf and AmdSmmCpuFeatureLib.inf. Will make the statement clear. The file naming above would be changed to <arch><OriginalFileName>.inf as Mike suggested.

I am not sure if there is another example having arch-specific INF file. Usually the driver module has the abstract interface and the implementation in the library module. A newly introduced processor architecture driver may create it’s own module such as ArmCpuDxe if the delta between implementations  is huge. However, I would prefer to have arch-specific INF for the module if the module implementation can be leveraged. And yes, this requires the discussion between contributor and module maintainer if the principles can not perfectly identify the case.

                     B-2. Source files
                              The new arch implementation is introduced to the module in order to leverage the source code and the module design architecture, so

  *   That is contributor’s responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific and arch-specific-feature wordings in the file name. Create a common file for the common implementation otherwise.

     *   The file naming for the arch-specific file

<OriginalFileName ><arch>.*

     *   The file naming for the common implementation

< OriginalFileNaming >Common.*

  *   That is contributor’s responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor’s responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module
[Ray] If you check the MpInitLib, most of SEV logic are moved to AmdSev.c. But MpLib.c still contains logic to call functions from AmdSev.c based on some AMD specific check. In my opinion, that’s already good enough.
[Chang, Abner]  I am not quite lean to the If-AMD-else in the source file solution. I prefer to separate AMD stuff or vendor feature to a separated file. So we can have the reviewer or maintainer for *Amd* files/module/packages specifically. This makes the review responsibility clear and efficient.
[Ray] You can take a look at the MpInitLib. There are some code paths that are AMD only. I agree to have dedicated reviewers from different vendors if the implementations are different.

However, if you check MdeModulePkg/DxeIpl, implementations for different archs are in different *folders*.
Can we leave this to the module owner to decide how to place the implementations?




  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.
[Chang, Abner] We will move the arch implementation to the arch folder without moving INF. This wont impact the platform DSC and FDF, however this has the impact to the existing overwrite.
[Ray] I might misunderstand your idea as “UefiCpuPkg/CpuDxe -> UefiCpuPkg/X86/CpuDxe”.
Now I guess you tries to say: “UefiCpuPkg/CpuDxe -> UefiCpuPkg/CpuDxe/X86”. That looks good to me.
We need a more clear statement here😊


  *   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.
[Chang, Abner] right, so the first bullet is important.

[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.


  1.  The files reconstruction:

B-1. The module INF metafile

  *   The existing INF file should be kept without the relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.

     *   < OriginalFileNaming><arch>.inf



B-2. Source files
                             The new arch implementation is introduced to this module in order to leverage the source code and the module design architecture, so

  *   That is contributor’s responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific wording in the file name. Create a common file for the common implementation otherwise.

     *   The file naming for the arch-specific source file

< OriginalFileNaming ><arch>.*

     *   The file naming for the common implementation

<OriginalFileNaming>Common.*

  *   That is contributor’s responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor’s responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module



  1.  When a new arch implementation has a huge delta with the original implementation

Create a separate module instance. The naming of the module should follow below format,

  *   Add the arch prefix with the original module name:

< OriginalModuleNaming><arch>



[-- Attachment #2: Type: text/html, Size: 29150 bytes --]

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

[Chang, Abner]

[-- Attachment #1: Type: text/plain, Size: 11190 bytes --]

[AMD Official Use Only - General]



From: Ni, Ray <ray.ni@intel.com>
Sent: Wednesday, September 28, 2022 1:43 PM
To: devel@edk2.groups.io; Chang, Abner <Abner.Chang@amd.com>
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Sunil V L <sunilvl@ventanamicro.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.

Abner,
I think we Mike’s first email regarding the package structure is a good guideline regarding how to place the modules.

What we are discussing is how to organize the module internal contents for different archs. Do you agree?
[Chang, Abner] Yes.
I want to clarify this so we have a clear boundary between the two topics.

However, Mike’s proposal also defines the <arch> folder inside a module directory.
Maybe we just work together to refine Mike’s proposal and document it in EDKII coding standard document.
[Chang, Abner] we can start from that and see how to accommodate the module reconstruction principles. I am modifying edk2 C coding standard spec to add the section for naming rule Mike proposed. Will send the patch for this later.
Thanks
Abner

Chao, can you check Mike’s proposal and raise if there is anything not captured?

Thanks,
Ray

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


[AMD Official Use Only - General]



From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Ni, Ray via groups.io
Sent: Wednesday, September 28, 2022 11:34 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>
Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Leif Lindholm <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish <afish@apple.com<mailto: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.

The [Arch] refers to the Processor Architecture.
The [Module] refer to the EDK2 module.
The [X86] refers to both IA32 and X64.
The principles to create the X86 folder in the module:

  1.  When X86-vendor’s implementation is introduced to the existing module:

  1.  The folder reconstruction:
A-1. If the module is obviously used by IA32/X64 only

  *   No need to create X86 folder
  *   Create X86-vendor’s stuff under the root directory of module
A-2. If the existing module is expected to accommodate the different archs or the module already has multiple archs:

  *   Create X86 folder
  *   Create X86-vendor’s stuff under X86 folder
[Ray] Looks good.


  1.  The files reconstruction:
B-1. The module INF metafile

  *   The existing INF metafile should be kept without relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.

     *   <OriginalFileName><arch>.inf
[Ray]  “CpuDxe.inf” and “CpuDxeArm.inf”? is that your intention? New developers may be confused that CpuDxe.inf supports only X86 arch.
Do you have an example that one module supporting multiple archs using different INF files? MdeModulePkg/DxeIpl is a module supporting different archs with the same INF file.
Or shall we leave it to be decided between the patch contributor and package/module maintainer?
[Chang, Abner]  Here I mean the library module, for example SmmCpuFeatureLib.inf and AmdSmmCpuFeatureLib.inf. Will make the statement clear. The file naming above would be changed to <arch><OriginalFileName>.inf as Mike suggested.

I am not sure if there is another example having arch-specific INF file. Usually the driver module has the abstract interface and the implementation in the library module. A newly introduced processor architecture driver may create it’s own module such as ArmCpuDxe if the delta between implementations  is huge. However, I would prefer to have arch-specific INF for the module if the module implementation can be leveraged. And yes, this requires the discussion between contributor and module maintainer if the principles can not perfectly identify the case.

                     B-2. Source files
                              The new arch implementation is introduced to the module in order to leverage the source code and the module design architecture, so

  *   That is contributor’s responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific and arch-specific-feature wordings in the file name. Create a common file for the common implementation otherwise.

     *   The file naming for the arch-specific file

<OriginalFileName ><arch>.*

     *   The file naming for the common implementation

< OriginalFileNaming >Common.*

  *   That is contributor’s responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor’s responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module
[Ray] If you check the MpInitLib, most of SEV logic are moved to AmdSev.c. But MpLib.c still contains logic to call functions from AmdSev.c based on some AMD specific check. In my opinion, that’s already good enough.
[Chang, Abner]  I am not quite lean to the If-AMD-else in the source file solution. I prefer to separate AMD stuff or vendor feature to a separated file. So we can have the reviewer or maintainer for *Amd* files/module/packages specifically. This makes the review responsibility clear and efficient.
[Ray] You can take a look at the MpInitLib. There are some code paths that are AMD only. I agree to have dedicated reviewers from different vendors if the implementations are different.

However, if you check MdeModulePkg/DxeIpl, implementations for different archs are in different *folders*.
Can we leave this to the module owner to decide how to place the implementations?




  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.
[Chang, Abner] We will move the arch implementation to the arch folder without moving INF. This wont impact the platform DSC and FDF, however this has the impact to the existing overwrite.
[Ray] I might misunderstand your idea as “UefiCpuPkg/CpuDxe -> UefiCpuPkg/X86/CpuDxe”.
Now I guess you tries to say: “UefiCpuPkg/CpuDxe -> UefiCpuPkg/CpuDxe/X86”. That looks good to me.
We need a more clear statement here😊


  *   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.
[Chang, Abner] right, so the first bullet is important.

[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.


  1.  The files reconstruction:

B-1. The module INF metafile

  *   The existing INF file should be kept without the relocation. Should not have the impacts to the existing DSC/FDF file.
  *   The new introduced INF metafile should be located under the root directory of module with the file naming format as below. This keeps the consistent module file structure.

     *   < OriginalFileNaming><arch>.inf



B-2. Source files
                             The new arch implementation is introduced to this module in order to leverage the source code and the module design architecture, so

  *   That is contributor’s responsibility to review the source code and strip the arch-dependent code away and put it into the arch-specific file. Leave the common code in the original file if there is no arch-specific wording in the file name. Create a common file for the common implementation otherwise.

     *   The file naming for the arch-specific source file

< OriginalFileNaming ><arch>.*

     *   The file naming for the common implementation

<OriginalFileNaming>Common.*

  *   That is contributor’s responsibility to relocate the arch-specific source files to the arch-specific folder.
  *   That is contributor’s responsibility to make sure the original INF metafile can properly pull-in the source file from arch-specific folder after the source file reconstruction.
  *   The common source files should be located under the root directory of module



  1.  When a new arch implementation has a huge delta with the original implementation

Create a separate module instance. The naming of the module should follow below format,

  *   Add the arch prefix with the original module name:

< OriginalModuleNaming><arch>



[-- Attachment #2: Type: text/html, Size: 32278 bytes --]

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

[Sunil V L]

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://github.com/tianocore/edk2-staging/commit/bba1a11be47dd091734e185afbed73ea75708749
https://github.com/tianocore/edk2-staging/commit/7fccf92a97a6d0618a20f10622220e78b3687906

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

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

[Chang, Abner]

[-- Attachment #1: Type: text/plain, Size: 4642 bytes --]

[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://github.com/tianocore-docs/edk2-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%2F%2Fgith
> 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%2F%2Fgith
> 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

[-- Attachment #2: Type: message/rfc822, Size: 22410 bytes --]

From: "Chang, Abner via groups.io" <abner.chang=amd.com@groups.io>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: Ray Ni <ray.ni@intel.com>, Michael D Kinney <michael.d.kinney@intel.com>, Sunil V L <sunilvl@ventanamicro.com>, "Attar, AbdulLateef (Abdul Lateef)" <AbdulLateef.Attar@amd.com>
Subject: [edk2-devel] [tianocore-docs][PATCH] edk II C Coding Standard: File and directory naming guidelines
Date: Wed, 28 Sep 2022 14:44:49 +0000
Message-ID: <17190D706DD1B11D.9603@groups.io>

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


From: Abner Chang <abner.chang@amd.com>

Add file and directory naming guidelines for EDKII modules. Also
consider the processor architecture and vendor implementation.

This is the draft version to community for the wide discussion.

PR
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore-docs%2Fedk2-CCodingStandardsSpecification%2Fpull%2F2&amp;data=05%7C01%7Cabner.chang%40amd.com%7C9a5163b4e0724bfac5ce08daa1600fa9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637999731204161847%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=O3PPK9Mfeh5HfDb%2FR5p3aLq1dh5X0eR80HbLGHxgD%2FM%3D&amp;reserved=0

Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Cc: Abdul Lateef Attar <abdattar@amd.com>
---
 4_naming_conventions/42_file_names.md      | 124 +++++++++++++++++++++
 4_naming_conventions/46_directory_names.md | 114 +++++++++++++++++++
 2 files changed, 238 insertions(+)
 create mode 100644 4_naming_conventions/46_directory_names.md

diff --git a/4_naming_conventions/42_file_names.md b/4_naming_conventions/42_file_names.md
index f948763..e7c10b5 100644
--- a/4_naming_conventions/42_file_names.md
+++ b/4_naming_conventions/42_file_names.md
@@ -58,3 +58,127 @@ regular expression:

 That is, a letter followed by zero, or more, letters, underscores, dashes, or
 digits followed by a period followed by one or more letters or digits.
+
+### 4.2.5 File naming guidelines for modules
+
+Below sections are the file naming guidelines for EDK II meta files and source files.
+
+#### 4.2.5.1 EDK II meta files within a package
+
+```
+<PackageName>Pkg.dec
+<PackageName>Pkg.dsc
+
+   <PackageName> REQUIRED  *
+```
+
+#### 4.2.5.2 EDK II INF file within a Module instance
+* If the implementation supports >=2 or all CPU archs:
+```
+<ModuleName><Phase>.inf
+
+   <ModuleName>   REQUIRED    *
+   <Phase>        REQUIRED    Base, Sec, Pei, Dxe, DxeRuntime, Mm, StandaloneMm,
+                              Smm, Uefi.
+
+Example:
+   CpuIo2Dxe.inf
+```
+
+* If the implementation of CPU arch or vendor shares some code in the module. Or the implementation is only for the specific CPU arch or vendor.
+```
+<ModuleName><Phase><CpuArch><Vendor>.inf
+
+   <ModuleName>   REQUIRED    *
+   <Phase>        REQUIRED    Base, Sec, Pei, Dxe, DxeRuntime, Mm,
+                              StandaloneMm, Smm, Uefi.
+   <CpuArch>      OPTIONAL    Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc, X86
+                              (X86 implies Ia32 and X64).
+   <Vendor>       OPTIONAL    *
+
+Example:
+   CpuIo2DxeAmd.inf
+```
+
+If the implementation does not have any shared code between phases. The module INF is located under \<Feature\>/\<Phase\> or \<Feature\>/<Phase\>/<CpuArch\>/<Vendor\> (see section 4.6 Directory Names).
+
+* If the implementation supports >=2 or all CPU archs:
+```
+<Feature>/<Phase>/<ModuleName>.inf
+
+   <Feature>      OPTIONAL    *
+   <Phase>        REQUIRED    Base, Sec, Pei, Dxe, DxeRuntime, Mm, StandaloneMm, Smm,
+                              Uefi.
+   <ModuleName>   REQUIRED    Same as <Feature>
+
+Example:
+   PCD/Dxe/Pcd.inf
+```
+
+* If the implementation of CPU arch or vendor shares some code in the module. Or the implementation is only for the specific CPU arch or vendor.
+```
+<Feature>/<Phase>/<ModuleName><CpuArch><Vendor>.inf
+
+   <Feature>      OPTIONAL    *
+   <Phase>        REQUIRED    Base, Sec, Pei, Dxe, DxeRuntime, Mm, StandaloneMm, Smm,
+                              Uefi.
+   <CpuArch>      OPTIONAL    Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc, X86
+                              (X86 implies Ia32 and X64).
+   <Vendor>       OPTIONAL    *
+   <ModuleName>   REQUIRED    Same as <Feature>
+
+```
+#### 4.2.5.3 EDK II INF file within a Library instance
+```
+<Phase><CpuArch><Vendor><LibraryClassName><Dependency>.inf
+   <Phase>              REQUIRED     Base, Sec, Pei, Dxe, DxeRuntime, Mm,
+                                     StandaloneMm, Smm, Uefi.
+   <CpuArch>            OPTIONAL     Ia32, X64, Arm, AArch64, RiscV64, LoongArch64,
+                                     Ebc, X86 (X86 implies Ia32 and X64).
+   <Vendor>             OPTIONAL     *
+   <LibraryClassName>   REQUIRED     *
+   <Dependency>         OPTIONAL     * (Typically name of PPI, Protocol, LibraryClass
+                                       that the implementation is layered on top of)
+
+Example:
+   SmmAmdSmmCpuFeaturesLib.inf
+   SmmIntelSmmCpuFeaturesLib.inf
+```
+
+#### 4.2.5.4 EDK II source files within a Library/Module instance
+
+```
+<FileName>.c
+<FileName>.h
+<CpuArch><Vendor><FileName>.c
+<CpuArch><Vendor><FileName>.h
+<CpuArch>/<FileName>.c
+<CpuArch>/<FileName>.h
+<CpuArch>/<FileName>.nasm
+<CpuArch>/<FileName>.S
+<CpuArch>/<Vendor>/<FileName>.c
+<CpuArch>/<Vendor>/<FileName>.h
+<CpuArch>/<Vendor>/<FileName>.nasm
+<CpuArch>/<Vendor>/<FileName>.S
+
+   <CpuArch> OPTIONAL   Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc, X86
+                        (X86 implies Ia32 and X64).
+   <Vendor>  OPTIONAL   *
+
+Example:
+   IA32/SmiException.nasm
+   X64/SmiException.nasm
+   SmmCpuFeatureLib.c
+   SmmCpuFeatureLibCommon.c
+   IntelSmmCpuFeaturesLib.c
+   AmdSmmCpuFeaturesLib.c
+
+   Or,
+   X86/IA32/SmiException.nasm
+   X86/X64/SmiException.nasm
+   X86/IntelSmmCpuFeaturesLib.c
+   X86/AmdSmmCpuFeaturesLib.c
+   RiscV64/JustAnExampleLib.c
+   SmmCpuFeatureLib.c
+   SmmCpuFeatureLibCommon.c
+```
diff --git a/4_naming_conventions/46_directory_names.md b/4_naming_conventions/46_directory_names.md
new file mode 100644
index 0000000..e4df796
--- /dev/null
+++ b/4_naming_conventions/46_directory_names.md
@@ -0,0 +1,114 @@
+<!--- @file
+  4.6 Directory Names
+
+  Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
+
+  Redistribution and use in source (original document form) and 'compiled'
+  forms (converted to PDF, epub, HTML and other formats) with or without
+  modification, are permitted provided that the following conditions are met:
+
+  1) Redistributions of source code (original document form) must retain the
+     above copyright notice, this list of conditions and the following
+     disclaimer as the first lines of this file unmodified.
+
+  2) Redistributions in compiled form (transformed to other DTDs, converted to
+     PDF, epub, HTML and other formats) must reproduce the above copyright
+     notice, this list of conditions and the following disclaimer in the
+     documentation and/or other materials provided with the distribution.
+
+  THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS OR
+  IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+  EVENT SHALL TIANOCORE PROJECT  BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+  PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+  OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+  WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+  OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
+  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+-->
+
+## 4.6 Directory Names
+Below sections are the directory naming guidelines for EDK II modules
+
+#### 4.6.1 EDKII package directory
+
+```
+<PackageName>Pkg
+
+   <PackageName> REQUIRED  *
+```
+
+#### 4.6.2 EDKII Module directory
+
+* If the implementation supports >=2 or all CPU archs:
+```
+<ModuleName><Phase>
+
+   <Phase>        REQUIRED    Base, Sec, Pei, Dxe, DxeRuntime, Mm, StandaloneMm, Smm,
+                              Uefi.
+   <ModuleName>   REQUIRED    *
+
+Example:
+   CpuDxe/
+```
+
+* If the implementation is for the specific CPU arch or vendor:
+```
+<ModuleName><Phase><CpuArch><Vendor>
+
+   <ModuleName>   REQUIRED    *
+   <Phase>        REQUIRED    Base, Sec, Pei, Dxe, DxeRuntime, Mm,
+                              StandaloneMm, Smm, Uefi.
+   <CpuArch>      OPTIONAL    Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc, X86
+                              (X86 implies Ia32 and X64).
+   <Vendor>       OPTIONAL    *
+
+Example:
+   CpuDxeRiscv64/
+```
+
+* If the implementation does not have any shared code between phases (e.g.
+MdeModulePkg/Universal/PCD) and supports >=2 or all CPU archs:
+
+```
+<Feature>/<Phase>
+
+   <Feature>      OPTIONAL    *
+   <Phase>        REQUIRED    Base, Sec, Pei, Dxe, DxeRuntime, Mm, StandaloneMm, Smm,
+                              Uefi.
+
+Example:
+   Pcd/Dxe/
+```
+
+* If the implementation does not have any shared code between phases (e.g.
+MdeModulePkg/Universal/PCD) and is for the specifc CPU arch or vendor:
+```
+<Feature>/<Phase>/<CpuArch>/<Vendor>
+
+   <Feature>      OPTIONAL    *
+   <Phase>        REQUIRED    Base, Sec, Pei, Dxe, DxeRuntime, Mm, StandaloneMm, Smm,
+                              Uefi.
+   <CpuArch>      OPTIONAL    Ia32, X64, Arm, AArch64, RiscV64, LoongArch64, Ebc, X86
+                              (X86 implies Ia32 and X64).
+   <Vendor>       OPTIONAL    *
+```
+
+#### 4.6.2 EDKII Library directory
+```
+<Phase><CpuArch><Vendor><LibraryClassName><Dependency>
+
+   <Phase>              REQUIRED     Base, Sec, Pei, Dxe, DxeRuntime, Mm,
+                                     StandaloneMm, Smm, Uefi.
+   <CpuArch>            OPTIONAL     Ia32, X64, Arm, AArch64, RiscV64, LoongArch64,
+                                     Ebc, X86 (X86 implies Ia32 and X64).
+   <Vendor>             OPTIONAL     *
+   <LibraryClassName>   REQUIRED     *
+   <Dependency>         OPTIONAL     * (Typically name of PPI, Protocol, LibraryClass
+                                       that the implementation is layered on top of).
+
+Example:
+   SmmAmdSmmCpuFeaturesLib/
+```
--
2.37.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94466): https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F94466&amp;data=05%7C01%7Cabner.chang%40amd.com%7C9a5163b4e0724bfac5ce08daa1600fa9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637999731204161847%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=KKnHsum9mc679b06mYD6s83ovN37LAulBdctW3pT86I%3D&amp;reserved=0
Mute This Topic: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.io%2Fmt%2F93974077%2F7039027&amp;data=05%7C01%7Cabner.chang%40amd.com%7C9a5163b4e0724bfac5ce08daa1600fa9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637999731204161847%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=lpbs%2B0DO5HZJzktqu6juC%2FW%2BAOYyqJsOQg9lSe%2FUwRI%3D&amp;reserved=0
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Funsub&amp;data=05%7C01%7Cabner.chang%40amd.com%7C9a5163b4e0724bfac5ce08daa1600fa9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637999731204161847%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=1grbxhLEwUuA%2BbEPu3%2BCEk5p4B4L5czqP%2FAIVhTVOhE%3D&amp;reserved=0 [abner.chang@amd.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Attar, AbdulLateef (Abdul Lateef)]

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://github.com/tianocore-docs/edk2-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%2F%2Fgith
> 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%2F%2Fgith
> 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

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

[Ni, Ray]

Abner,
Comments in https://github.com/tianocore-docs/edk2-CCodingStandardsSpecification/pull/2#pullrequestreview-1124763311

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://github.com/tianocore-docs/edk2-
> 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%2F%2Fgith
> > 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%2F%2Fgith
> > 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

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

[Ni, Ray]

Sunil, I don't have concern with your changes.
Perhaps you can also move all existing source files to X86 folder.

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Sunil V L
> Sent: Wednesday, September 28, 2022 3:34 PM
> To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>
> Cc: 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
> 
> 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://github.com/tianocore/edk2-
> staging/commit/bba1a11be47dd091734e185afbed73ea75708749
> https://github.com/tianocore/edk2-
> staging/commit/7fccf92a97a6d0618a20f10622220e78b3687906
> 
> 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
> 
> 
> 
> 
> 

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

[Chang, Abner]

[AMD Official Use Only - General]

Hi Sunil,
One more thing other than the module reconstruction for archs before you sending patch to edk2:
Not sure how would you do on migrating the RISC-V code from edk2-platforms to edk2.  Did you make some other changes to the RISC-V CpuDxe on edk2-platform?
Please keep the files history and send the patch for the migration first.  Then have the follow up patches for your changes if any and also add the Ventana license.

Below branches could be the reference for this migration,
https://github.com/changab/edk2/commits/RISC-V-MIGRATION-EDK2-PR
https://github.com/changab/edk2-platforms/commits/RISC-V-MIGRATION-EDK2-PLATFORM

Thanks Sunil.
Abner

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ni, Ray
> via groups.io
> Sent: Thursday, September 29, 2022 3:48 PM
> To: devel@edk2.groups.io; sunilvl@ventanamicro.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.
> 
> 
> Sunil, I don't have concern with your changes.
> Perhaps you can also move all existing source files to X86 folder.
> 
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Sunil V
> > L
> > Sent: Wednesday, September 28, 2022 3:34 PM
> > To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>
> > Cc: 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
> >
> > 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%2F%2Fgith
> > ub.com%2Ftianocore%2Fedk2-
> &amp;data=05%7C01%7Cabner.chang%40amd.com%7C
> >
> 84150fde7ae94437a06908daa1eee77a%7C3dd8961fe4884e608e11a82d994e18
> 3d%7C
> >
> 0%7C0%7C638000344717043181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDA
> >
> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
> amp;sd
> >
> ata=P0QZ8%2B3IxaTnoEJPYOn3SgDLGhLZohPna53RoX6o2sc%3D&amp;reserv
> ed=0
> > staging/commit/bba1a11be47dd091734e185afbed73ea75708749
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Ftianocore%2Fedk2-
> &amp;data=05%7C01%7Cabner.chang%40amd.com%7C
> >
> 84150fde7ae94437a06908daa1eee77a%7C3dd8961fe4884e608e11a82d994e18
> 3d%7C
> >
> 0%7C0%7C638000344717043181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDA
> >
> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
> amp;sd
> >
> ata=P0QZ8%2B3IxaTnoEJPYOn3SgDLGhLZohPna53RoX6o2sc%3D&amp;reserv
> ed=0
> > staging/commit/7fccf92a97a6d0618a20f10622220e78b3687906
> >
> > 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
> >
> >
> >
> >
> >
> 
> 
> 
> 
> 

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

[Sunil V L]

On Thu, Sep 29, 2022 at 02:54:05PM +0000, Chang, Abner wrote:
> [AMD Official Use Only - General]
> 
> Hi Sunil,
> One more thing other than the module reconstruction for archs before you sending patch to edk2:
> Not sure how would you do on migrating the RISC-V code from edk2-platforms to edk2.  Did you make some other changes to the RISC-V CpuDxe on edk2-platform?
> Please keep the files history and send the patch for the migration first.  Then have the follow up patches for your changes if any and also add the Ventana license.
> 
> Below branches could be the reference for this migration,
> https://github.com/changab/edk2/commits/RISC-V-MIGRATION-EDK2-PR
> https://github.com/changab/edk2-platforms/commits/RISC-V-MIGRATION-EDK2-PLATFORM
> 
> Thanks Sunil.
> Abner
> 
Thanks Abner. Let me take a look at your branch.

We have some changes and are not migrating everything from
edk2-platforms. But I am not sure whether we can maintain the commit
history when we migrate from a different repo. I think this should be like a 
new review and all old RB tags which were for edk2-platforms need to be removed.

For ex:
https://github.com/changab/edk2/commit/eca5ff6bea66be94fd58421ba98cb54d1f4181a6

IMO, RB tag should be removed and should be reviewed fresh when it is
being added to edk2 repo.

Thanks
Sunil

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

[Chang, Abner]

[AMD Official Use Only - General]



> -----Original Message-----
> From: Sunil V L <sunilvl@ventanamicro.com>
> Sent: Thursday, September 29, 2022 11:22 PM
> To: Chang, Abner <Abner.Chang@amd.com>
> Cc: devel@edk2.groups.io; ray.ni@intel.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 Thu, Sep 29, 2022 at 02:54:05PM +0000, Chang, Abner wrote:
> > [AMD Official Use Only - General]
> >
> > Hi Sunil,
> > One more thing other than the module reconstruction for archs before you
> sending patch to edk2:
> > Not sure how would you do on migrating the RISC-V code from edk2-
> platforms to edk2.  Did you make some other changes to the RISC-V CpuDxe
> on edk2-platform?
> > Please keep the files history and send the patch for the migration first.
> Then have the follow up patches for your changes if any and also add the
> Ventana license.
> >
> > Below branches could be the reference for this migration,
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Fchangab%2Fedk2%2Fcommits%2FRISC-V-MIGRATION-EDK2-
> PR&amp;data=
> >
> 05%7C01%7CAbner.Chang%40amd.com%7Cb644f4b61bbd4e096c2308daa22e
> 6703%7C3
> >
> dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638000617445410044%7C
> Unknown
> >
> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLCJ
> >
> XVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=wRnI%2Br4Dunydf77gSClb
> 6ghHuY24Qs
> > LrZTiPqc7pP1I%3D&amp;reserved=0
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Fchangab%2Fedk2-platforms%2Fcommits%2FRISC-V-
> MIGRATION-EDK2-PL
> >
> ATFORM&amp;data=05%7C01%7CAbner.Chang%40amd.com%7Cb644f4b61b
> bd4e096c23
> >
> 08daa22e6703%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63800
> 0617445
> >
> 410044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
> luMzIiLCJ
> >
> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=5T2PHJOj
> %2Bk6Mmu
> > zNn0vsELm0raYiIDiI1X%2FekgZt6ls%3D&amp;reserved=0
> >
> > Thanks Sunil.
> > Abner
> >
> Thanks Abner. Let me take a look at your branch.
> 
> We have some changes and are not migrating everything from edk2-
> platforms. But I am not sure whether we can maintain the commit history
> when we migrate from a different repo. I think this should be like a new
> review and all old RB tags which were for edk2-platforms need to be
> removed.
I was used tool to cherry pick from different repo to keep the history. Not sure if git command line can do this or not.

To treat it as a new file that includes HPE and Ventana copyrights is confusing because HPE didn't have the collaboration with Ventana on those source files. I think you would have some files that are modified by Ventana regarding the functionality and some files without any change; the copyright should be applied to the contribution of functionality but not the migration or build error fix for the migration. I am fine with having a new review process, however, I would suggest below steps for the files from edk2-platform if to keep history is difficult.

1. Migrate the code from edk2-platform and fix the build error on edk2. In the source file keep HPE copyright only. Mention the origin of the file in the commit message. Please do not add Ventana copyright to the source file at this moment.
2. Afterward, add Ventana copyright for the further updates. This makes the contribution clear.
3. Do not delete the one on edk2-platforms. I think we can mention the implementation is obsoleted in the Readme.md under RISC-V PlatformPkg and ProcessorPkg.

BTW, I can help on CpuDxe X86 migration.

Thanks
Abner
> 
> For ex:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fchangab%2Fedk2%2Fcommit%2Feca5ff6bea66be94fd58421ba98c
> b54d1f4181a6&amp;data=05%7C01%7CAbner.Chang%40amd.com%7Cb644f4
> b61bbd4e096c2308daa22e6703%7C3dd8961fe4884e608e11a82d994e183d%7C
> 0%7C0%7C638000617445566273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> %7C%7C%7C&amp;sdata=2TRD8pySU%2FIhz7ttFwdCHtPpl6JM0YSp%2BZjvo5
> %2FEEZ4%3D&amp;reserved=0
> 
> IMO, RB tag should be removed and should be reviewed fresh when it is
> being added to edk2 repo.
> 
> Thanks
> Sunil

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

[Chang, Abner]

[AMD Official Use Only - General]

Thanks Ray, here are my responses. 
https://github.com/tianocore-docs/edk2-CCodingStandardsSpecification/pull/2

@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%2F%2Fgith
> ub.com%2Ftianocore-docs%2Fedk2-
> CCodingStandardsSpecification%2Fpull%2F2%23pullrequestreview-
> 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%2F%2Fgith
> > 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%2F%2Fgith
> > > 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%2F%2Fgith
> > > 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

The principles of EDK2 module reconstruction for archs (wiki page on tianocore.github.io)

[Chang, Abner]

[AMD Official Use Only - General]

Hi all,
Addition to the File and Directory Names in EDK II C Coding standard spec, here is the draft of wiki page for reconstructing the existing module for processor arch and vendor implementation.
https://github.com/changab/tianocore.github.io/wiki/The-Principles-of-EDK2-Module-Reconstruction-for-the-Processor-Architecture

Thanks
Abner

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

[Michael D Kinney]

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://github.com/tianocore-docs/edk2-CCodingStandardsSpecification/pull/2
> 
> @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%2F%2Fgith
> > ub.com%2Ftianocore-docs%2Fedk2-
> > CCodingStandardsSpecification%2Fpull%2F2%23pullrequestreview-
> > 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%2F%2Fgith
> > > 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%2F%2Fgith
> > > > 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%2F%2Fgith
> > > > 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

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

[Leif Lindholm]

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://github.com/tianocore-docs/edk2-CCodingStandardsSpecification/pull/2
>>
>> @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%2F%2Fgith
>>> ub.com%2Ftianocore-docs%2Fedk2-
>>> CCodingStandardsSpecification%2Fpull%2F2%23pullrequestreview-
>>> 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%2F%2Fgith
>>>> 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%2F%2Fgith
>>>>> 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%2F%2Fgith
>>>>> 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
> 
> 
> 
> 
> 

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

[Michael D Kinney]

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://github.com/tianocore-docs/edk2-CCodingStandardsSpecification/pull/2
> >>
> >> @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%2F%2Fgith
> >>> ub.com%2Ftianocore-docs%2Fedk2-
> >>> CCodingStandardsSpecification%2Fpull%2F2%23pullrequestreview-
> >>> 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%2F%2Fgith
> >>>> 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%2F%2Fgith
> >>>>> 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%2F%2Fgith
> >>>>> 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
> >
> >
> >
> >
> >
> 
> 
> 
> 
> 

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

[Chang, Abner]

[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://edk2.groups.io/g/devel/message/94567
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%3A%2F%2Fg
> > >> ithub.com%2Ftianocore-docs%2Fedk2-CCodingStandardsSpecification%2Fp
> > >>
> ull%2F2&amp;data=05%7C01%7CAbner.Chang%40amd.com%7C7c3292c8bd2f4
> 86f
> > >>
> 920908daa314e8e6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6
> 3800
> > >>
> 1607445876768%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
> 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%2F%2F
> > >>> gith
> > >>> ub.com%2Ftianocore-docs%2Fedk2-
> > >>> CCodingStandardsSpecification%2Fpull%2F2%23pullrequestreview-
> > >>>
> 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%2F%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%2F%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%2F%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
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > 
> >

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

[Michael D Kinney]

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://edk2.groups.io/g/devel/message/94567
> 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%3A%2F%2Fg
> > > >> ithub.com%2Ftianocore-docs%2Fedk2-CCodingStandardsSpecification%2Fp
> > > >>
> > ull%2F2&amp;data=05%7C01%7CAbner.Chang%40amd.com%7C7c3292c8bd2f4
> > 86f
> > > >>
> > 920908daa314e8e6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6
> > 3800
> > > >>
> > 1607445876768%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
> > 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%2F%2F
> > > >>> gith
> > > >>> ub.com%2Ftianocore-docs%2Fedk2-
> > > >>> CCodingStandardsSpecification%2Fpull%2F2%23pullrequestreview-
> > > >>>
> > 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%2F%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%2F%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%2F%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
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > 
> > >

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

[Chang, Abner]

[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.

Do you agree with the arch concatenate solution for arch folder? That means IA32_X64 instead of X86 (I am fine with this)? 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?

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%2Fedk
> 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%3A%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%23pullrequestreview-
> > > > >>>
> > >
> 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > 
> > > >

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

[Michael D Kinney]

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

> 
> 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.

> 
> 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%2Fedk
> > 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%3A%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%23pullrequestreview-
> > > > > >>>
> > > >
> > 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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> 
> 
> 
> 

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

[Chang, Abner]

[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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> >
> >
> > 
> >

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

[Michael D Kinney]

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%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
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > >
> > >
> > > 
> > >

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

[Chang, Abner]

[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@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%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=htt
> > > > > > > > >> 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%23pullrequest
> > > > > > > > >>> revi
> > > > > > > > >>> 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=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
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > >
> > > >
> > > > 
> > > >

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

[Chang, Abner]

[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@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://github.com/tianocore-docs/edk2-
> 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%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=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%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=
> > > > > > > > > >>> 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
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > >
> > > > >
> > > > > 
> > > > >

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

[Ni, Ray]

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://edk2.groups.io/g/devel/message/94912?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Arecentpostdate%2Fsticky%2C%2CUefiCpuPkg%2FCpuTimerLib%2C20%2C2%2C0%2C94233015

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://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@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://github.com/tianocore-docs/edk2-
> > 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
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > >
> > > > > >
> > > > > > 
> > > > > >

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

[Chang, Abner]

[-- Attachment #1: Type: text/plain, Size: 40137 bytes --]

[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

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
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
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > >
> > > > > >
> > > > > > 
> > > > > >

[-- Attachment #2: Type: text/html, Size: 73063 bytes --]

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

[Michael D Kinney]

[-- Attachment #1: Type: text/plain, Size: 47097 bytes --]

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

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Sent: Tuesday, October 11, 2022 9:51:24 AM
To: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com> <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<mailto:Abner.Chang@amd.com>>
> Sent: Thursday, October 6, 2022 4:37 PM
> To: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef
> (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He,
> Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<mailto:michael.d.kinney@intel.com>>;
> devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef
> > (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> He,
> > Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<mailto:michael.d.kinney@intel.com>>
> > > Sent: Tuesday, October 4, 2022 10:18 PM
> > > To: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > > quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar,
> > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; Kinney, Michael D
> > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > He,
> > > Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<mailto:Abner.Chang@amd.com>>
> > > > Sent: Tuesday, October 4, 2022 7:05 AM
> > > > To: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray
> > > > <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef (Abdul Lateef)
> > > > <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish
> <afish@apple.com<mailto: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<mailto:michael.d.kinney@intel.com>>
> > > > > Sent: Tuesday, October 4, 2022 12:54 AM
> > > > > To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>;
> > > > > quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar,
> > > > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; Kinney, Michael D
> > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish
> > <afish@apple.com<mailto: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<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto: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<mailto:michael.d.kinney@intel.com>>;
> > > > > > devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray
> > > > > > <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> > > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > He,
> > > > > > Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<mailto:michael.d.kinney@intel.com>>
> > > > > > > Sent: Monday, October 3, 2022 1:18 PM
> > > > > > > To: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>;
> > devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > > > > > > quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar,
> > > > > > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil
> > > > > > > V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; Kinney, Michael D
> > > > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang
> <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>;
> > > > > > > Andrew Fish <afish@apple.com<mailto: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<mailto:Abner.Chang@amd.com>>
> > > > > > > > Sent: Sunday, October 2, 2022 8:13 PM
> > > > > > > > To: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > > > > > devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray
> > > > > > > > <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > > > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> > > > > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > > > He,
> > > > > > > > Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish
> > > > > > > > <afish@apple.com<mailto: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<mailto:michael.d.kinney@intel.com>>
> > > > > > > > > Sent: Saturday, October 1, 2022 2:52 AM
> > > > > > > > > To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>;
> > > > > > > > > Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Ni, Ray
> > > > > > > > > <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > > > > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; Kinney, Michael D
> > > > > > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > > > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang
> > <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>;
> > > > > > > > > Andrew Fish <afish@apple.com<mailto: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<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On
> > > > > > > > > > Behalf Of Leif Lindholm
> > > > > > > > > > Sent: Friday, September 30, 2022 9:09 AM
> > > > > > > > > > To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Kinney, Michael D
> > > > > > > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Chang, Abner
> > > > > > > <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>;
> > > > > > > > > > Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef (Abdul
> > > > > > > > > > Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > > > > > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> > > > > > > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > > > > > > He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish
> > > > > > > <afish@apple.com<mailto: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<mailto:Abner.Chang@amd.com>>
> > > > > > > > > > >> Sent: Friday, September 30, 2022 12:11 AM
> > > > > > > > > > >> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef
> > > > > > > > > > >> (Abdul
> > > > > > > > > > >> Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > > > > > > >> <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > > > > > > > > > >> Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > > > > > > > >> Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > >> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > > >> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang
> > > > > <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>;
> > > > > > > Leif
> > > > > > > > > > >> Lindholm <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish
> > > > > > > > > > >> <afish@apple.com<mailto: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<mailto:ray.ni@intel.com>>
> > > > > > > > > > >>> Sent: Thursday, September 29, 2022 3:42 PM
> > > > > > > > > > >>> To: Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > > >>> <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Chang, Abner
> > > > > > > > > > >>> <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Sunil V L
> > > > > > > > > > >>> <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> > > > > > > > > > >>> Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > > > > > > > >>> lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > >>> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > > >>> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang
> > > > > <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>;
> > > > > > > > > > >>> Leif Lindholm <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew
> > > > > > > > > > >>> Fish <afish@apple.com<mailto: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<mailto:AbdulLateef.Attar@amd.com>>
> > > > > > > > > > >>>> Sent: Thursday, September 29, 2022 3:11 PM
> > > > > > > > > > >>>> To: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Sunil V L
> > > > > > > > > > >>>> <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > > > > > > > > > >>>> Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > > > > > > > > > >>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > > > > > > > >>>> lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > >>>> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > > >>>> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > > > > > > >>> He,
> > > > > > > > > > >>>> Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Leif Lindholm
> > > > > > > > > > >>>> <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish
> > > > > > > > > > >>>> <afish@apple.com<mailto: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<mailto:abdattar@amd.com>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Thanks
> > > > > > > > > > >>>> AbduL
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> -----Original Message-----
> > > > > > > > > > >>>> From: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>
> > > > > > > > > > >>>> Sent: 28 September 2022 20:31
> > > > > > > > > > >>>> To: Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>;
> > > > > > > > > > >>>> devel@edk2.groups.io<mailto:devel@edk2.groups.io>; ray.ni@intel.com<mailto:ray.ni@intel.com>
> > > > > > > > > > >>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > > > > > > > >>>> lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > >>>> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > > >>>> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > > > > > > >>> He,
> > > > > > > > > > >>>> Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Attar, AbdulLateef
> > > > > > > > > > >>>> (Abdul
> > > > > > > > > > >>>> Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Leif Lindholm
> > > > > > > > > > >>>> <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish
> > > > > > > > > > >>>> <afish@apple.com<mailto: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<mailto:sunilvl@ventanamicro.com>>
> > > > > > > > > > >>>>> Sent: Wednesday, September 28, 2022 3:34 PM
> > > > > > > > > > >>>>> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; ray.ni@intel.com<mailto:ray.ni@intel.com>
> > > > > > > > > > >>>>> Cc: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Kinney,
> > > > > Michael
> > > > > > > > > > >>>>> D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; lichao
> > > > > > > > > > >>>>> <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > >>>>> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > > >>>>> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang
> > > > > > > > > > >>>>> <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Attar, AbdulLateef (Abdul
> > > > > > > > > > >>>>> Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Leif
> Lindholm
> > > > > > > > > > >>>>> <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish
> > > > > > > > > > >>>>> <afish@apple.com<mailto: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
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > >
> > > > > >
> > > > > > 
> > > > > >

[-- Attachment #2: Type: text/html, Size: 123353 bytes --]

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

[Chang, Abner]

[-- Attachment #1: Type: text/plain, Size: 50230 bytes --]

[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<mailto:Abner.Chang@amd.com>>
Sent: Monday, October 10, 2022 7:21 PM
To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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

Get Outlook for Android<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2FAAb9ysg&data=05%7C01%7CAbner.Chang%40amd.com%7Cb307b466eac14cd33e0b08daabc5723b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638011161764300122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=34mZNzuk%2Fe2CA6t1ElERtGvoxB0VN4mO7p%2FJi43VjDo%3D&reserved=0>
________________________________
From: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Sent: Tuesday, October 11, 2022 9:51:24 AM
To: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com> <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<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&data=05%7C01%7CAbner.Chang%40amd.com%7Cb307b466eac14cd33e0b08daabc5723b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638011161764300122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GC%2B5uk9nY1ba%2FX6rDMc38wibJOTBFDrU2OVN3yex%2Bd4%3D&reserved=0>

Thanks,
Ray

> -----Original Message-----
> From: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>
> Sent: Thursday, October 6, 2022 4:37 PM
> To: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef
> (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He,
> Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchangab%2Ftianocore.github.io%2Fwiki%2FThe-Guidelines-of-&data=05%7C01%7CAbner.Chang%40amd.com%7Cb307b466eac14cd33e0b08daabc5723b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638011161764300122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=j514pWQ5PHpWwOTkZ1CwgQDrCiNXhBA69TOj4ffzr%2Fk%3D&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<mailto:michael.d.kinney@intel.com>>;
> devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef
> > (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> He,
> > Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore-docs%2Fedk2-&data=05%7C01%7CAbner.Chang%40amd.com%7Cb307b466eac14cd33e0b08daabc5723b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638011161764300122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sdom8PP6dHC0Bu4BelSx7gGEbhZz8gMhlrmLiwwzygg%3D&reserved=0>
> > CCodingStandardsSpecification/pull/2/commits. Please check it.
> >
> > Thanks
> > Abner
> >
> > > -----Original Message-----
> > > From: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > Sent: Tuesday, October 4, 2022 10:18 PM
> > > To: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > > quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar,
> > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; Kinney, Michael D
> > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > He,
> > > Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<mailto:Abner.Chang@amd.com>>
> > > > Sent: Tuesday, October 4, 2022 7:05 AM
> > > > To: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray
> > > > <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef (Abdul Lateef)
> > > > <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish
> <afish@apple.com<mailto: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<mailto:michael.d.kinney@intel.com>>
> > > > > Sent: Tuesday, October 4, 2022 12:54 AM
> > > > > To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>;
> > > > > quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar,
> > > > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; Kinney, Michael D
> > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish
> > <afish@apple.com<mailto: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<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto: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<mailto:michael.d.kinney@intel.com>>;
> > > > > > devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray
> > > > > > <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> > > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > He,
> > > > > > Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<mailto:michael.d.kinney@intel.com>>
> > > > > > > Sent: Monday, October 3, 2022 1:18 PM
> > > > > > > To: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>;
> > devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > > > > > > quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar,
> > > > > > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil
> > > > > > > V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; Kinney, Michael D
> > > > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang
> <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>;
> > > > > > > Andrew Fish <afish@apple.com<mailto: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<mailto:Abner.Chang@amd.com>>
> > > > > > > > Sent: Sunday, October 2, 2022 8:13 PM
> > > > > > > > To: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > > > > > devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray
> > > > > > > > <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > > > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> > > > > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > > > He,
> > > > > > > > Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish
> > > > > > > > <afish@apple.com<mailto: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<mailto:michael.d.kinney@intel.com>>
> > > > > > > > > Sent: Saturday, October 1, 2022 2:52 AM
> > > > > > > > > To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>;
> > > > > > > > > Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Ni, Ray
> > > > > > > > > <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > > > > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; Kinney, Michael D
> > > > > > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > > > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang
> > <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>;
> > > > > > > > > Andrew Fish <afish@apple.com<mailto: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<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On
> > > > > > > > > > Behalf Of Leif Lindholm
> > > > > > > > > > Sent: Friday, September 30, 2022 9:09 AM
> > > > > > > > > > To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Kinney, Michael D
> > > > > > > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Chang, Abner
> > > > > > > <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>;
> > > > > > > > > > Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef (Abdul
> > > > > > > > > > Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > > > > > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> > > > > > > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > > > > > > He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish
> > > > > > > <afish@apple.com<mailto: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<mailto:Abner.Chang@amd.com>>
> > > > > > > > > > >> Sent: Friday, September 30, 2022 12:11 AM
> > > > > > > > > > >> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef
> > > > > > > > > > >> (Abdul
> > > > > > > > > > >> Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > > > > > > >> <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > > > > > > > > > >> Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > > > > > > > >> Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > >> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > > >> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang
> > > > > <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>;
> > > > > > > Leif
> > > > > > > > > > >> Lindholm <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish
> > > > > > > > > > >> <afish@apple.com<mailto: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<mailto:ray.ni@intel.com>>
> > > > > > > > > > >>> Sent: Thursday, September 29, 2022 3:42 PM
> > > > > > > > > > >>> To: Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > > >>> <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Chang, Abner
> > > > > > > > > > >>> <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Sunil V L
> > > > > > > > > > >>> <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> > > > > > > > > > >>> Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > > > > > > > >>> lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > >>> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > > >>> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang
> > > > > <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>;
> > > > > > > > > > >>> Leif Lindholm <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew
> > > > > > > > > > >>> Fish <afish@apple.com<mailto: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<mailto:AbdulLateef.Attar@amd.com>>
> > > > > > > > > > >>>> Sent: Thursday, September 29, 2022 3:11 PM
> > > > > > > > > > >>>> To: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Sunil V L
> > > > > > > > > > >>>> <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > > > > > > > > > >>>> Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > > > > > > > > > >>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > > > > > > > >>>> lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > >>>> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > > >>>> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > > > > > > >>> He,
> > > > > > > > > > >>>> Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Leif Lindholm
> > > > > > > > > > >>>> <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish
> > > > > > > > > > >>>> <afish@apple.com<mailto: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<mailto:abdattar@amd.com>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Thanks
> > > > > > > > > > >>>> AbduL
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> -----Original Message-----
> > > > > > > > > > >>>> From: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>
> > > > > > > > > > >>>> Sent: 28 September 2022 20:31
> > > > > > > > > > >>>> To: Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>;
> > > > > > > > > > >>>> devel@edk2.groups.io<mailto:devel@edk2.groups.io>; ray.ni@intel.com<mailto:ray.ni@intel.com>
> > > > > > > > > > >>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > > > > > > > >>>> lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > >>>> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > > >>>> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > > > > > > >>> He,
> > > > > > > > > > >>>> Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Attar, AbdulLateef
> > > > > > > > > > >>>> (Abdul
> > > > > > > > > > >>>> Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Leif Lindholm
> > > > > > > > > > >>>> <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish
> > > > > > > > > > >>>> <afish@apple.com<mailto: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<mailto:sunilvl@ventanamicro.com>>
> > > > > > > > > > >>>>> Sent: Wednesday, September 28, 2022 3:34 PM
> > > > > > > > > > >>>>> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; ray.ni@intel.com<mailto:ray.ni@intel.com>
> > > > > > > > > > >>>>> Cc: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Kinney,
> > > > > Michael
> > > > > > > > > > >>>>> D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; lichao
> > > > > > > > > > >>>>> <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > >>>>> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > > >>>>> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang
> > > > > > > > > > >>>>> <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Attar, AbdulLateef (Abdul
> > > > > > > > > > >>>>> Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Leif
> Lindholm
> > > > > > > > > > >>>>> <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish
> > > > > > > > > > >>>>> <afish@apple.com<mailto: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
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > >
> > > > > >
> > > > > > 
> > > > > >

[-- Attachment #2: Type: text/html, Size: 89649 bytes --]

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

[Michael D Kinney]

[-- Attachment #1: Type: text/plain, Size: 51988 bytes --]

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<mailto:michael.d.kinney@intel.com>>
Sent: Wednesday, October 12, 2022 4:16 AM
To: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<mailto:Abner.Chang@amd.com>>
Sent: Monday, October 10, 2022 7:21 PM
To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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

Get Outlook for Android<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2FAAb9ysg&data=05%7C01%7CAbner.Chang%40amd.com%7Cb307b466eac14cd33e0b08daabc5723b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638011161764300122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=34mZNzuk%2Fe2CA6t1ElERtGvoxB0VN4mO7p%2FJi43VjDo%3D&reserved=0>
________________________________
From: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Sent: Tuesday, October 11, 2022 9:51:24 AM
To: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com> <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<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&data=05%7C01%7CAbner.Chang%40amd.com%7Cb307b466eac14cd33e0b08daabc5723b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638011161764300122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GC%2B5uk9nY1ba%2FX6rDMc38wibJOTBFDrU2OVN3yex%2Bd4%3D&reserved=0>

Thanks,
Ray

> -----Original Message-----
> From: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>
> Sent: Thursday, October 6, 2022 4:37 PM
> To: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef
> (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He,
> Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchangab%2Ftianocore.github.io%2Fwiki%2FThe-Guidelines-of-&data=05%7C01%7CAbner.Chang%40amd.com%7Cb307b466eac14cd33e0b08daabc5723b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638011161764300122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=j514pWQ5PHpWwOTkZ1CwgQDrCiNXhBA69TOj4ffzr%2Fk%3D&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<mailto:michael.d.kinney@intel.com>>;
> devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef
> > (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> He,
> > Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore-docs%2Fedk2-&data=05%7C01%7CAbner.Chang%40amd.com%7Cb307b466eac14cd33e0b08daabc5723b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638011161764300122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sdom8PP6dHC0Bu4BelSx7gGEbhZz8gMhlrmLiwwzygg%3D&reserved=0>
> > CCodingStandardsSpecification/pull/2/commits. Please check it.
> >
> > Thanks
> > Abner
> >
> > > -----Original Message-----
> > > From: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > Sent: Tuesday, October 4, 2022 10:18 PM
> > > To: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > > quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar,
> > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; Kinney, Michael D
> > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > He,
> > > Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<mailto:Abner.Chang@amd.com>>
> > > > Sent: Tuesday, October 4, 2022 7:05 AM
> > > > To: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray
> > > > <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef (Abdul Lateef)
> > > > <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish
> <afish@apple.com<mailto: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<mailto:michael.d.kinney@intel.com>>
> > > > > Sent: Tuesday, October 4, 2022 12:54 AM
> > > > > To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>;
> > > > > quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar,
> > > > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; Kinney, Michael D
> > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish
> > <afish@apple.com<mailto: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<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto: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<mailto:michael.d.kinney@intel.com>>;
> > > > > > devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray
> > > > > > <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> > > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > He,
> > > > > > Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<mailto:michael.d.kinney@intel.com>>
> > > > > > > Sent: Monday, October 3, 2022 1:18 PM
> > > > > > > To: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>;
> > devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > > > > > > quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar,
> > > > > > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil
> > > > > > > V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; Kinney, Michael D
> > > > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang
> <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>;
> > > > > > > Andrew Fish <afish@apple.com<mailto: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<mailto:Abner.Chang@amd.com>>
> > > > > > > > Sent: Sunday, October 2, 2022 8:13 PM
> > > > > > > > To: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > > > > > devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray
> > > > > > > > <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > > > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> > > > > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > > > He,
> > > > > > > > Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish
> > > > > > > > <afish@apple.com<mailto: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<mailto:michael.d.kinney@intel.com>>
> > > > > > > > > Sent: Saturday, October 1, 2022 2:52 AM
> > > > > > > > > To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>;
> > > > > > > > > Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Ni, Ray
> > > > > > > > > <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > > > > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; Kinney, Michael D
> > > > > > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > > > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang
> > <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>;
> > > > > > > > > Andrew Fish <afish@apple.com<mailto: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<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On
> > > > > > > > > > Behalf Of Leif Lindholm
> > > > > > > > > > Sent: Friday, September 30, 2022 9:09 AM
> > > > > > > > > > To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Kinney, Michael D
> > > > > > > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Chang, Abner
> > > > > > > <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>;
> > > > > > > > > > Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef (Abdul
> > > > > > > > > > Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > > > > > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> > > > > > > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > > > > > > He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish
> > > > > > > <afish@apple.com<mailto: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<mailto:Abner.Chang@amd.com>>
> > > > > > > > > > >> Sent: Friday, September 30, 2022 12:11 AM
> > > > > > > > > > >> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef
> > > > > > > > > > >> (Abdul
> > > > > > > > > > >> Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > > > > > > >> <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > > > > > > > > > >> Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > > > > > > > >> Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > >> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > > >> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang
> > > > > <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>;
> > > > > > > Leif
> > > > > > > > > > >> Lindholm <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish
> > > > > > > > > > >> <afish@apple.com<mailto: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<mailto:ray.ni@intel.com>>
> > > > > > > > > > >>> Sent: Thursday, September 29, 2022 3:42 PM
> > > > > > > > > > >>> To: Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > > >>> <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Chang, Abner
> > > > > > > > > > >>> <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Sunil V L
> > > > > > > > > > >>> <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> > > > > > > > > > >>> Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > > > > > > > >>> lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > >>> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > > >>> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang
> > > > > <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>;
> > > > > > > > > > >>> Leif Lindholm <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew
> > > > > > > > > > >>> Fish <afish@apple.com<mailto: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<mailto:AbdulLateef.Attar@amd.com>>
> > > > > > > > > > >>>> Sent: Thursday, September 29, 2022 3:11 PM
> > > > > > > > > > >>>> To: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Sunil V L
> > > > > > > > > > >>>> <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > > > > > > > > > >>>> Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > > > > > > > > > >>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > > > > > > > >>>> lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > >>>> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > > >>>> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > > > > > > >>> He,
> > > > > > > > > > >>>> Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Leif Lindholm
> > > > > > > > > > >>>> <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish
> > > > > > > > > > >>>> <afish@apple.com<mailto: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<mailto:abdattar@amd.com>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Thanks
> > > > > > > > > > >>>> AbduL
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> -----Original Message-----
> > > > > > > > > > >>>> From: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>
> > > > > > > > > > >>>> Sent: 28 September 2022 20:31
> > > > > > > > > > >>>> To: Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>;
> > > > > > > > > > >>>> devel@edk2.groups.io<mailto:devel@edk2.groups.io>; ray.ni@intel.com<mailto:ray.ni@intel.com>
> > > > > > > > > > >>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > > > > > > > >>>> lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > >>>> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > > >>>> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > > > > > > >>> He,
> > > > > > > > > > >>>> Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Attar, AbdulLateef
> > > > > > > > > > >>>> (Abdul
> > > > > > > > > > >>>> Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Leif Lindholm
> > > > > > > > > > >>>> <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish
> > > > > > > > > > >>>> <afish@apple.com<mailto: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<mailto:sunilvl@ventanamicro.com>>
> > > > > > > > > > >>>>> Sent: Wednesday, September 28, 2022 3:34 PM
> > > > > > > > > > >>>>> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; ray.ni@intel.com<mailto:ray.ni@intel.com>
> > > > > > > > > > >>>>> Cc: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Kinney,
> > > > > Michael
> > > > > > > > > > >>>>> D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; lichao
> > > > > > > > > > >>>>> <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > >>>>> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > > >>>>> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang
> > > > > > > > > > >>>>> <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Attar, AbdulLateef (Abdul
> > > > > > > > > > >>>>> Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Leif
> Lindholm
> > > > > > > > > > >>>>> <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish
> > > > > > > > > > >>>>> <afish@apple.com<mailto: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
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > >
> > > > > >
> > > > > > 
> > > > > >

[-- Attachment #2: Type: text/html, Size: 131313 bytes --]

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

[Chang, Abner]

[-- Attachment #1: Type: text/plain, Size: 53255 bytes --]

[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<mailto:Abner.Chang@amd.com>>
Sent: Tuesday, October 11, 2022 5:52 PM
To: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<mailto:michael.d.kinney@intel.com>>
Sent: Wednesday, October 12, 2022 4:16 AM
To: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<mailto:Abner.Chang@amd.com>>
Sent: Monday, October 10, 2022 7:21 PM
To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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

Get Outlook for Android<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2FAAb9ysg&data=05%7C01%7CAbner.Chang%40amd.com%7Cb3abed3b0c2f4a738af208daabee6ede%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638011337819178442%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ns4V91paG%2F1mMHvTJAg2qrk3qk5LfgP5EPSbF%2FFUt8s%3D&reserved=0>
________________________________
From: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Sent: Tuesday, October 11, 2022 9:51:24 AM
To: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com> <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<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&data=05%7C01%7CAbner.Chang%40amd.com%7Cb3abed3b0c2f4a738af208daabee6ede%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638011337819178442%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TCSE2GjeuNqAZXQQk2tav0dlQ%2B2Qeeu67c96AzbiIFY%3D&reserved=0>

Thanks,
Ray

> -----Original Message-----
> From: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>
> Sent: Thursday, October 6, 2022 4:37 PM
> To: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef
> (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He,
> Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchangab%2Ftianocore.github.io%2Fwiki%2FThe-Guidelines-of-&data=05%7C01%7CAbner.Chang%40amd.com%7Cb3abed3b0c2f4a738af208daabee6ede%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638011337819178442%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VkV1n8XTI8zW5Di4YhygcDqankUYvvlw2mP3iaEbMwg%3D&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<mailto:michael.d.kinney@intel.com>>;
> devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef
> > (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> He,
> > Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore-docs%2Fedk2-&data=05%7C01%7CAbner.Chang%40amd.com%7Cb3abed3b0c2f4a738af208daabee6ede%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638011337819178442%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Lptlc5Q0nCeefX9oqeqRGW5h2uslrU%2BMyQinq37xXtI%3D&reserved=0>
> > CCodingStandardsSpecification/pull/2/commits. Please check it.
> >
> > Thanks
> > Abner
> >
> > > -----Original Message-----
> > > From: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > Sent: Tuesday, October 4, 2022 10:18 PM
> > > To: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > > quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar,
> > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; Kinney, Michael D
> > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > He,
> > > Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<mailto:Abner.Chang@amd.com>>
> > > > Sent: Tuesday, October 4, 2022 7:05 AM
> > > > To: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray
> > > > <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef (Abdul Lateef)
> > > > <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish
> <afish@apple.com<mailto: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<mailto:michael.d.kinney@intel.com>>
> > > > > Sent: Tuesday, October 4, 2022 12:54 AM
> > > > > To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>;
> > > > > quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar,
> > > > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; Kinney, Michael D
> > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish
> > <afish@apple.com<mailto: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<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto: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<mailto:michael.d.kinney@intel.com>>;
> > > > > > devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray
> > > > > > <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> > > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > He,
> > > > > > Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish <afish@apple.com<mailto: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<mailto:michael.d.kinney@intel.com>>
> > > > > > > Sent: Monday, October 3, 2022 1:18 PM
> > > > > > > To: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>;
> > devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > > > > > > quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar,
> > > > > > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil
> > > > > > > V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; Kinney, Michael D
> > > > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang
> <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>;
> > > > > > > Andrew Fish <afish@apple.com<mailto: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<mailto:Abner.Chang@amd.com>>
> > > > > > > > Sent: Sunday, October 2, 2022 8:13 PM
> > > > > > > > To: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > > > > > devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>; Ni, Ray
> > > > > > > > <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > > > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> > > > > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > > > He,
> > > > > > > > Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish
> > > > > > > > <afish@apple.com<mailto: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<mailto:michael.d.kinney@intel.com>>
> > > > > > > > > Sent: Saturday, October 1, 2022 2:52 AM
> > > > > > > > > To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>;
> > > > > > > > > Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Ni, Ray
> > > > > > > > > <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > > > > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; Kinney, Michael D
> > > > > > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > > > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang
> > <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>;
> > > > > > > > > Andrew Fish <afish@apple.com<mailto: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<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On
> > > > > > > > > > Behalf Of Leif Lindholm
> > > > > > > > > > Sent: Friday, September 30, 2022 9:09 AM
> > > > > > > > > > To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Kinney, Michael D
> > > > > > > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Chang, Abner
> > > > > > > <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>;
> > > > > > > > > > Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef (Abdul
> > > > > > > > > > Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > > > > > > <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>
> > > > > > > > > > Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > > > > > > He, Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Andrew Fish
> > > > > > > <afish@apple.com<mailto: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<mailto:Abner.Chang@amd.com>>
> > > > > > > > > > >> Sent: Friday, September 30, 2022 12:11 AM
> > > > > > > > > > >> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Attar, AbdulLateef
> > > > > > > > > > >> (Abdul
> > > > > > > > > > >> Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Sunil V L
> > > > > > > > > > >> <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > > > > > > > > > >> Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > > > > > > > >> Cc: lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > >> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > > >> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang
> > > > > <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>;
> > > > > > > Leif
> > > > > > > > > > >> Lindholm <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish
> > > > > > > > > > >> <afish@apple.com<mailto: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<mailto:ray.ni@intel.com>>
> > > > > > > > > > >>> Sent: Thursday, September 29, 2022 3:42 PM
> > > > > > > > > > >>> To: Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > > >>> <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Chang, Abner
> > > > > > > > > > >>> <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Sunil V L
> > > > > > > > > > >>> <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> > > > > > > > > > >>> Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > > > > > > > >>> lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > >>> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > > >>> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang
> > > > > <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>;
> > > > > > > > > > >>> Leif Lindholm <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew
> > > > > > > > > > >>> Fish <afish@apple.com<mailto: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<mailto:AbdulLateef.Attar@amd.com>>
> > > > > > > > > > >>>> Sent: Thursday, September 29, 2022 3:11 PM
> > > > > > > > > > >>>> To: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Sunil V L
> > > > > > > > > > >>>> <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > > > > > > > > > >>>> Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > > > > > > > > > >>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > > > > > > > >>>> lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > >>>> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > > >>>> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > > > > > > >>> He,
> > > > > > > > > > >>>> Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Leif Lindholm
> > > > > > > > > > >>>> <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish
> > > > > > > > > > >>>> <afish@apple.com<mailto: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<mailto:abdattar@amd.com>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Thanks
> > > > > > > > > > >>>> AbduL
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> -----Original Message-----
> > > > > > > > > > >>>> From: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>
> > > > > > > > > > >>>> Sent: 28 September 2022 20:31
> > > > > > > > > > >>>> To: Sunil V L <sunilvl@ventanamicro.com<mailto:sunilvl@ventanamicro.com>>;
> > > > > > > > > > >>>> devel@edk2.groups.io<mailto:devel@edk2.groups.io>; ray.ni@intel.com<mailto:ray.ni@intel.com>
> > > > > > > > > > >>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > > > > > > > >>>> lichao <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > >>>> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > > >>>> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>;
> > > > > > > > > > >>> He,
> > > > > > > > > > >>>> Jiangang <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Attar, AbdulLateef
> > > > > > > > > > >>>> (Abdul
> > > > > > > > > > >>>> Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Leif Lindholm
> > > > > > > > > > >>>> <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish
> > > > > > > > > > >>>> <afish@apple.com<mailto: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<mailto:sunilvl@ventanamicro.com>>
> > > > > > > > > > >>>>> Sent: Wednesday, September 28, 2022 3:34 PM
> > > > > > > > > > >>>>> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; ray.ni@intel.com<mailto:ray.ni@intel.com>
> > > > > > > > > > >>>>> Cc: Chang, Abner <Abner.Chang@amd.com<mailto:Abner.Chang@amd.com>>; Kinney,
> > > > > Michael
> > > > > > > > > > >>>>> D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; lichao
> > > > > > > > > > >>>>> <lichao@loongson.cn<mailto:lichao@loongson.cn>>; Kirkendall, Garrett
> > > > > > > > > > >>>>> <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>; Grimes, Paul
> > > > > > > > > > >>>>> <Paul.Grimes@amd.com<mailto:Paul.Grimes@amd.com>>; He, Jiangang
> > > > > > > > > > >>>>> <Jiangang.He@amd.com<mailto:Jiangang.He@amd.com>>; Attar, AbdulLateef (Abdul
> > > > > > > > > > >>>>> Lateef) <AbdulLateef.Attar@amd.com<mailto:AbdulLateef.Attar@amd.com>>; Leif
> Lindholm
> > > > > > > > > > >>>>> <quic_llindhol@quicinc.com<mailto:quic_llindhol@quicinc.com>>; Andrew Fish
> > > > > > > > > > >>>>> <afish@apple.com<mailto: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
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > >
> > > > > >
> > > > > > 
> > > > > >

[-- Attachment #2: Type: text/html, Size: 95828 bytes --]