[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 <suni...@ventanamicro.com>
> Sent: Wednesday, September 28, 2022 3:34 PM
> To: devel@edk2.groups.io; ray...@intel.com
> Cc: Chang, Abner <abner.ch...@amd.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>; lichao <lic...@loongson.cn>; Kirkendall,
> Garrett <garrett.kirkend...@amd.com>; Grimes, Paul
> <paul.gri...@amd.com>; He, Jiangang <jiangang...@amd.com>; Attar,
> AbdulLateef (Abdul Lateef) <abdullateef.at...@amd.com>; Leif Lindholm
> <quic_llind...@quicinc.com>; Andrew Fish <af...@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


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94467): https://edk2.groups.io/g/devel/message/94467
Mute This Topic: https://groups.io/mt/93872791/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


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


From: Abner Chang <abner.ch...@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.ch...@amd.com>
Cc: Ray Ni <ray...@intel.com>
Cc: Michael D Kinney <michael.d.kin...@intel.com>
Cc: Sunil V L <suni...@ventanamicro.com>
Cc: Abdul Lateef Attar <abdat...@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+ow...@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.ch...@amd.com]
-=-=-=-=-=-=-=-=-=-=-=-



--- End Message ---

Reply via email to