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

[Chang, Abner via groups.io]

[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 
Sent: Wednesday, October 12, 2022 4:16 AM
To: Chang, Abner ; Ni, Ray ; 
devel@edk2.groups.io; quic_llind...@quicinc.com; Attar, AbdulLateef (Abdul 
Lateef) ; Sunil V L ; 
Kinney, Michael D 
Cc: lichao ; Kirkendall, Garrett 
; Grimes, Paul ; He, Jiangang 
; Andrew Fish 
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 mailto:abner.ch...@amd.com>>
Sent: Monday, October 10, 2022 7:21 PM
To: Ni, Ray mailto:ray...@intel.com>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; 
devel@edk2.groups.io; 
quic_llind...@quicinc.com; Attar, AbdulLateef 
(Abdul Lateef) mailto:abdullateef.at...@amd.com>>; 
Sunil V L mailto:suni...@ventanamicro.com>>
Cc: lichao mailto:lic...@loongson.cn>>; Kirkendall, Garrett 
mailto:garrett.kirkend...@amd.com>>; Grimes, Paul 
mailto:paul.gri...@amd.com>>; He, Jiangang 
mailto:jiangang...@amd.com>>; Andrew Fish 
mailto:af...@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

From: Ni, Ray mailto:ray...@intel.com>>
Sent: Tuesday, October 11, 2022 9:51:24 AM
To: Chang, Abner mailto:abner.ch...@amd.com>>; Kinney, 
Michael D mailto:michael.d.kin...@intel.com>>; 
devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>; 
quic_llind...@quicinc.com 
mailto:quic_llind...@quicinc.com>>; Attar, 
AbdulLateef (Abdul Lateef) 
mailto:abdullateef.at...@amd.com>>; Sunil V L 
mailto:suni...@ventanamicro.com>>
Cc: lichao mailto:lic...@loongson.cn>>; Kirkendall, Garrett 
mailto:garrett.kirkend...@amd.com>>; Grimes, Paul 
mailto:paul.gri...@amd.com>>; He, Jiangang 
mailto:jiangang...@amd.com>>; Andrew Fish 
mailto: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.


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%252C94233015data=05%7C01%7CAbner.Chang%40amd.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=5wOiTArZyySLos4A%2FQHOC3gryUIZ8K4SgNxeTwfANMY%3Dreserved=0

Thanks,
Ray

> -Original Message-
> From: Chang, Abner mailto:abner.ch...@amd.com>>
> Sent: Thursday, October 6, 2022 4:37 PM
> To: Kinney, Michael D 
> mailto:michael.d.kin...@intel.com>>; 
> devel@edk2.groups.io;
> 

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

[Chang, Abner via groups.io]

[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

From: Ni, Ray 
Sent: Tuesday, October 11, 2022 9:51:24 AM
To: Chang, Abner ; Kinney, Michael D 
; devel@edk2.groups.io ; 
quic_llind...@quicinc.com ; Attar, AbdulLateef 
(Abdul Lateef) ; Sunil V L 
Cc: lichao ; Kirkendall, Garrett 
; Grimes, Paul ; He, Jiangang 
; Andrew Fish 
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%252C94233015data=05%7C01%7CAbner.Chang%40amd.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=5wOiTArZyySLos4A%2FQHOC3gryUIZ8K4SgNxeTwfANMY%3Dreserved=0

Thanks,
Ray

> -Original Message-
> From: Chang, Abner 
> Sent: Thursday, October 6, 2022 4:37 PM
> To: Kinney, Michael D ; devel@edk2.groups.io;
> quic_llind...@quicinc.com; Ni, Ray ; Attar, AbdulLateef
> (Abdul Lateef) ; Sunil V L
> 
> Cc: lichao ; Kirkendall, Garrett
> ; Grimes, Paul ; He,
> Jiangang ; Andrew Fish 
> 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-data=05%7C01%7CAbner.Chang%40amd.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=i5RSe41cuzD48VB32KeG0M3Vp7T%2FEqe3ncKNfGCjfIU%3Dreserved=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 ;
> devel@edk2.groups.io;
> > quic_llind...@quicinc.com; Ni, Ray ; Attar, AbdulLateef
> > (Abdul Lateef) ; Sunil V L
> > 
> > Cc: lichao ; Kirkendall, Garrett
> > ; Grimes, Paul ;
> He,
> > Jiangang ; Andrew Fish 
> > 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-data=05%7C01%7CAbner.Chang%40amd.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=YDYXODgrQhuLlP8DTsLr%2F4ct2JH3aw8y2SPg8tk5fgg%3Dreserved=0
> > CCodingStandardsSpecification/pull/2/commits. Please check it.
> >
> > Thanks
> > Abner
> >
> > > -Original Message-
> > > From: Kinney, Michael D 
> > > Sent: Tuesday, October 4, 2022 10:18 PM
> > > To: Chang, Abner ; devel@edk2.groups.io;
> > > quic_llind...@quicinc.com; Ni, Ray ; Attar,
> > > AbdulLateef (Abdul Lateef) ; Sunil V L
> > > ; Kinney, Michael D
> > > 
> > > Cc: lichao ; Kirkendall, Garrett
> > > ; Grimes, Paul ;
> > He,
> > > Jiangang ; Andrew Fish 
> > > 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 
> > > > Sent: Tuesday, October 4, 2022 7:05 AM
> > > > To: Kinney, Michael D ;
> > > > devel@edk2.groups.io; quic_llind...@quicinc.com; Ni, 

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 
> Sent: Thursday, October 6, 2022 4:37 PM
> To: Kinney, Michael D ; devel@edk2.groups.io;
> quic_llind...@quicinc.com; Ni, Ray ; Attar, AbdulLateef
> (Abdul Lateef) ; Sunil V L
> 
> Cc: lichao ; Kirkendall, Garrett
> ; Grimes, Paul ; He,
> Jiangang ; Andrew Fish 
> 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 ;
> devel@edk2.groups.io;
> > quic_llind...@quicinc.com; Ni, Ray ; Attar, AbdulLateef
> > (Abdul Lateef) ; Sunil V L
> > 
> > Cc: lichao ; Kirkendall, Garrett
> > ; Grimes, Paul ;
> He,
> > Jiangang ; Andrew Fish 
> > 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 
> > > Sent: Tuesday, October 4, 2022 10:18 PM
> > > To: Chang, Abner ; devel@edk2.groups.io;
> > > quic_llind...@quicinc.com; Ni, Ray ; Attar,
> > > AbdulLateef (Abdul Lateef) ; Sunil V L
> > > ; Kinney, Michael D
> > > 
> > > Cc: lichao ; Kirkendall, Garrett
> > > ; Grimes, Paul ;
> > He,
> > > Jiangang ; Andrew Fish 
> > > 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 
> > > > Sent: Tuesday, October 4, 2022 7:05 AM
> > > > To: Kinney, Michael D ;
> > > > devel@edk2.groups.io; quic_llind...@quicinc.com; Ni, Ray
> > > > ; Attar, AbdulLateef (Abdul Lateef)
> > > > ; Sunil V L 
> > > > Cc: lichao ; Kirkendall, Garrett
> > > > ; Grimes, Paul
> ;
> > > > He, Jiangang ; Andrew Fish
> 
> > > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > > reconstruction for archs
> > > >
> > > > [AMD Official Use Only - General]
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Kinney, Michael D 
> > > > > Sent: Tuesday, October 4, 2022 12:54 AM
> > > > > To: devel@edk2.groups.io; Chang, Abner ;
> > > > > quic_llind...@quicinc.com; Ni, Ray ; Attar,
> > > > > AbdulLateef (Abdul Lateef) ; Sunil V L
> > > > > ; Kinney, Michael D
> > > > > 
> > > > > Cc: lichao ; Kirkendall, Garrett
> > > > > ; Grimes, Paul
> > ;
> > > > > He, Jiangang ; Andrew Fish
> > 
> > > > > 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  On Behalf Of
> > > > > > Chang, Abner via groups.io
> > > > > > Sent: Sunday, October 2, 2022 10:37 PM
> > > > > > To: Kinney, Michael D ;
> > > > > > devel@edk2.groups.io; quic_llind...@quicinc.com; Ni, Ray
> > > > > > ; Attar, AbdulLateef (Abdul Lateef)
> > > > > > ; Sunil V L
> > > > > > 
> > > > > > Cc: lichao ; Kirkendall, Garrett
> > > > > > ; Grimes, Paul
> > > > > > ;
> > > > > He,
> > > > > > Jiangang ; Andrew Fish 
> > > > > > 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 

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

[Chang, Abner via groups.io]

[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 ; devel@edk2.groups.io;
> quic_llind...@quicinc.com; Ni, Ray ; Attar, AbdulLateef
> (Abdul Lateef) ; Sunil V L
> 
> Cc: lichao ; Kirkendall, Garrett
> ; Grimes, Paul ; He,
> Jiangang ; Andrew Fish 
> 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 
> > Sent: Tuesday, October 4, 2022 10:18 PM
> > To: Chang, Abner ; devel@edk2.groups.io;
> > quic_llind...@quicinc.com; Ni, Ray ; Attar,
> > AbdulLateef (Abdul Lateef) ; Sunil V L
> > ; Kinney, Michael D
> > 
> > Cc: lichao ; Kirkendall, Garrett
> > ; Grimes, Paul ;
> He,
> > Jiangang ; Andrew Fish 
> > 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 
> > > Sent: Tuesday, October 4, 2022 7:05 AM
> > > To: Kinney, Michael D ;
> > > devel@edk2.groups.io; quic_llind...@quicinc.com; Ni, Ray
> > > ; Attar, AbdulLateef (Abdul Lateef)
> > > ; Sunil V L 
> > > Cc: lichao ; Kirkendall, Garrett
> > > ; Grimes, Paul ;
> > > He, Jiangang ; Andrew Fish 
> > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > reconstruction for archs
> > >
> > > [AMD Official Use Only - General]
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Kinney, Michael D 
> > > > Sent: Tuesday, October 4, 2022 12:54 AM
> > > > To: devel@edk2.groups.io; Chang, Abner ;
> > > > quic_llind...@quicinc.com; Ni, Ray ; Attar,
> > > > AbdulLateef (Abdul Lateef) ; Sunil V L
> > > > ; Kinney, Michael D
> > > > 
> > > > Cc: lichao ; Kirkendall, Garrett
> > > > ; Grimes, Paul
> ;
> > > > He, Jiangang ; Andrew Fish
> 
> > > > 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  On Behalf Of
> > > > > Chang, Abner via groups.io
> > > > > Sent: Sunday, October 2, 2022 10:37 PM
> > > > > To: Kinney, Michael D ;
> > > > > devel@edk2.groups.io; quic_llind...@quicinc.com; Ni, Ray
> > > > > ; Attar, AbdulLateef (Abdul Lateef)
> > > > > ; Sunil V L
> > > > > 
> > > > > Cc: lichao ; Kirkendall, Garrett
> > > > > ; Grimes, Paul
> > > > > ;
> > > > He,
> > > > > Jiangang ; Andrew Fish 
> > > > > 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 

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

[Chang, Abner via groups.io]

[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 
> Sent: Tuesday, October 4, 2022 10:18 PM
> To: Chang, Abner ; devel@edk2.groups.io;
> quic_llind...@quicinc.com; Ni, Ray ; Attar, AbdulLateef
> (Abdul Lateef) ; Sunil V L
> ; Kinney, Michael D 
> Cc: lichao ; Kirkendall, Garrett
> ; Grimes, Paul ; He,
> Jiangang ; Andrew Fish 
> 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 
> > Sent: Tuesday, October 4, 2022 7:05 AM
> > To: Kinney, Michael D ;
> > devel@edk2.groups.io; quic_llind...@quicinc.com; Ni, Ray
> > ; Attar, AbdulLateef (Abdul Lateef)
> > ; Sunil V L 
> > Cc: lichao ; Kirkendall, Garrett
> > ; Grimes, Paul ; He,
> > Jiangang ; Andrew Fish 
> > Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction
> > for archs
> >
> > [AMD Official Use Only - General]
> >
> >
> >
> > > -Original Message-
> > > From: Kinney, Michael D 
> > > Sent: Tuesday, October 4, 2022 12:54 AM
> > > To: devel@edk2.groups.io; Chang, Abner ;
> > > quic_llind...@quicinc.com; Ni, Ray ; Attar,
> > > AbdulLateef (Abdul Lateef) ; Sunil V L
> > > ; Kinney, Michael D
> > > 
> > > Cc: lichao ; Kirkendall, Garrett
> > > ; Grimes, Paul ;
> > > He, Jiangang ; Andrew Fish 
> > > 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  On Behalf Of
> > > > Chang, Abner via groups.io
> > > > Sent: Sunday, October 2, 2022 10:37 PM
> > > > To: Kinney, Michael D ;
> > > > devel@edk2.groups.io; quic_llind...@quicinc.com; Ni, Ray
> > > > ; Attar, AbdulLateef (Abdul Lateef)
> > > > ; Sunil V L 
> > > > Cc: lichao ; Kirkendall, Garrett
> > > > ; Grimes, Paul ;
> > > He,
> > > > Jiangang ; Andrew Fish 
> > > > 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 
> > > > > Sent: Monday, October 3, 2022 1:18 PM
> > > > > To: Chang, Abner ; devel@edk2.groups.io;
> > > > > quic_llind...@quicinc.com; Ni, Ray ; Attar,
> > > > > AbdulLateef (Abdul Lateef) ; Sunil V
> > > > > L ; Kinney, Michael D
> > > > > 
> > > > > Cc: lichao ; Kirkendall, Garrett
> > > > > ; Grimes, Paul
> > > > > ; He, Jiangang ;
> > 

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 
> Sent: Tuesday, October 4, 2022 7:05 AM
> To: Kinney, Michael D ; devel@edk2.groups.io; 
> quic_llind...@quicinc.com; Ni, Ray ;
> Attar, AbdulLateef (Abdul Lateef) ; Sunil V L 
> 
> Cc: lichao ; Kirkendall, Garrett 
> ; Grimes, Paul ; He,
> Jiangang ; Andrew Fish 
> Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for 
> archs
> 
> [AMD Official Use Only - General]
> 
> 
> 
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Tuesday, October 4, 2022 12:54 AM
> > To: devel@edk2.groups.io; Chang, Abner ;
> > quic_llind...@quicinc.com; Ni, Ray ; Attar, AbdulLateef
> > (Abdul Lateef) ; Sunil V L
> > ; Kinney, Michael D
> > 
> > Cc: lichao ; Kirkendall, Garrett
> > ; Grimes, Paul ; He,
> > Jiangang ; Andrew Fish 
> > 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  On Behalf Of Chang,
> > > Abner via groups.io
> > > Sent: Sunday, October 2, 2022 10:37 PM
> > > To: Kinney, Michael D ;
> > > devel@edk2.groups.io; quic_llind...@quicinc.com; Ni, Ray
> > > ; Attar, AbdulLateef (Abdul Lateef)
> > > ; Sunil V L 
> > > Cc: lichao ; Kirkendall, Garrett
> > > ; Grimes, Paul ;
> > He,
> > > Jiangang ; Andrew Fish 
> > > 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 
> > > > Sent: Monday, October 3, 2022 1:18 PM
> > > > To: Chang, Abner ; devel@edk2.groups.io;
> > > > quic_llind...@quicinc.com; Ni, Ray ; Attar,
> > > > AbdulLateef (Abdul Lateef) ; Sunil V L
> > > > ; Kinney, Michael D
> > > > 
> > > > Cc: lichao ; Kirkendall, Garrett
> > > > ; Grimes, Paul ;
> > > > He, Jiangang ; Andrew Fish 
> > > > 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 
> > > > > Sent: Sunday, October 2, 2022 8:13 PM
> > > > > To: Kinney, Michael D ;
> > > > > devel@edk2.groups.io; quic_llind...@quicinc.com; Ni, Ray
> > > > > ; Attar, AbdulLateef (Abdul Lateef)
> > > > > ; Sunil V L 
> > > > > Cc: lichao ; Kirkendall, Garrett
> > > > > ; Grimes, Paul
> > ;
> > > > He,
> > > > > Jiangang ; Andrew Fish 
> > > > > Subject: RE: 

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

[Chang, Abner via groups.io]

[AMD Official Use Only - General]



> -Original Message-
> From: Kinney, Michael D 
> Sent: Tuesday, October 4, 2022 12:54 AM
> To: devel@edk2.groups.io; Chang, Abner ;
> quic_llind...@quicinc.com; Ni, Ray ; Attar, AbdulLateef
> (Abdul Lateef) ; Sunil V L
> ; Kinney, Michael D
> 
> Cc: lichao ; Kirkendall, Garrett
> ; Grimes, Paul ; He,
> Jiangang ; Andrew Fish 
> 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  On Behalf Of Chang,
> > Abner via groups.io
> > Sent: Sunday, October 2, 2022 10:37 PM
> > To: Kinney, Michael D ;
> > devel@edk2.groups.io; quic_llind...@quicinc.com; Ni, Ray
> > ; Attar, AbdulLateef (Abdul Lateef)
> > ; Sunil V L 
> > Cc: lichao ; Kirkendall, Garrett
> > ; Grimes, Paul ;
> He,
> > Jiangang ; Andrew Fish 
> > 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 
> > > Sent: Monday, October 3, 2022 1:18 PM
> > > To: Chang, Abner ; devel@edk2.groups.io;
> > > quic_llind...@quicinc.com; Ni, Ray ; Attar,
> > > AbdulLateef (Abdul Lateef) ; Sunil V L
> > > ; Kinney, Michael D
> > > 
> > > Cc: lichao ; Kirkendall, Garrett
> > > ; Grimes, Paul ;
> > > He, Jiangang ; Andrew Fish 
> > > 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 
> > > > Sent: Sunday, October 2, 2022 8:13 PM
> > > > To: Kinney, Michael D ;
> > > > devel@edk2.groups.io; quic_llind...@quicinc.com; Ni, Ray
> > > > ; Attar, AbdulLateef (Abdul Lateef)
> > > > ; Sunil V L 
> > > > Cc: lichao ; Kirkendall, Garrett
> > > > ; Grimes, Paul
> ;
> > > He,
> > > > Jiangang ; Andrew Fish 
> > > > 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%2F94567data=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%7Csdata=eiLOC0G9WZWKqm2ALcAiKr7SPBP5AgDdAxogHlv5pI
> > > M%3Dr
> > > > eserved=0
> > > > SmmCpuFeatureLib\Ia32
> > > > SmmCpuFeatureLib\X64
> > > > SmmCpuFeatureLib\SmmCpuFeatureLib.c
> > 

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  On Behalf Of Chang, Abner 
> via groups.io
> Sent: Sunday, October 2, 2022 10:37 PM
> To: Kinney, Michael D ; devel@edk2.groups.io; 
> quic_llind...@quicinc.com; Ni, Ray ;
> Attar, AbdulLateef (Abdul Lateef) ; Sunil V L 
> 
> Cc: lichao ; Kirkendall, Garrett 
> ; Grimes, Paul ; He,
> Jiangang ; Andrew Fish 
> 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 
> > Sent: Monday, October 3, 2022 1:18 PM
> > To: Chang, Abner ; devel@edk2.groups.io;
> > quic_llind...@quicinc.com; Ni, Ray ; Attar, AbdulLateef
> > (Abdul Lateef) ; Sunil V L
> > ; Kinney, Michael D
> > 
> > Cc: lichao ; Kirkendall, Garrett
> > ; Grimes, Paul ; He,
> > Jiangang ; Andrew Fish 
> > 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 
> > > Sent: Sunday, October 2, 2022 8:13 PM
> > > To: Kinney, Michael D ;
> > > devel@edk2.groups.io; quic_llind...@quicinc.com; Ni, Ray
> > > ; Attar, AbdulLateef (Abdul Lateef)
> > > ; Sunil V L 
> > > Cc: lichao ; Kirkendall, Garrett
> > > ; Grimes, Paul ;
> > He,
> > > Jiangang ; Andrew Fish 
> > > 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%2F94567data=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%7Csdata=eiLOC0G9WZWKqm2ALcAiKr7SPBP5AgDdAxogHlv5pI
> > M%3Dr
> > > 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

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

[Chang, Abner via groups.io]

[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 
> Sent: Monday, October 3, 2022 1:18 PM
> To: Chang, Abner ; devel@edk2.groups.io;
> quic_llind...@quicinc.com; Ni, Ray ; Attar, AbdulLateef
> (Abdul Lateef) ; Sunil V L
> ; Kinney, Michael D
> 
> Cc: lichao ; Kirkendall, Garrett
> ; Grimes, Paul ; He,
> Jiangang ; Andrew Fish 
> 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 
> > Sent: Sunday, October 2, 2022 8:13 PM
> > To: Kinney, Michael D ;
> > devel@edk2.groups.io; quic_llind...@quicinc.com; Ni, Ray
> > ; Attar, AbdulLateef (Abdul Lateef)
> > ; Sunil V L 
> > Cc: lichao ; Kirkendall, Garrett
> > ; Grimes, Paul ;
> He,
> > Jiangang ; Andrew Fish 
> > 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%2F94567data=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%7Csdata=eiLOC0G9WZWKqm2ALcAiKr7SPBP5AgDdAxogHlv5pI
> M%3Dr
> > 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 
> > > Sent: Saturday, October 1, 2022 2:52 AM
> > > To: devel@edk2.groups.io; quic_llind...@quicinc.com; Chang, Abner
> > > ; Ni, Ray ; Attar,
> > > AbdulLateef (Abdul Lateef) ; Sunil V L
> > > ; Kinney, Michael D
> > > 
> > > Cc: lichao ; Kirkendall, Garrett
> > > ; Grimes, Paul ;
> > > He, Jiangang ; Andrew Fish 
> > > 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
> > 

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 
> Sent: Sunday, October 2, 2022 8:13 PM
> To: Kinney, Michael D ; devel@edk2.groups.io; 
> quic_llind...@quicinc.com; Ni, Ray ;
> Attar, AbdulLateef (Abdul Lateef) ; Sunil V L 
> 
> Cc: lichao ; Kirkendall, Garrett 
> ; Grimes, Paul ; He,
> Jiangang ; Andrew Fish 
> 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 
> > Sent: Saturday, October 1, 2022 2:52 AM
> > To: devel@edk2.groups.io; quic_llind...@quicinc.com; Chang, Abner
> > ; Ni, Ray ; Attar, AbdulLateef
> > (Abdul Lateef) ; Sunil V L
> > ; Kinney, Michael D 
> > Cc: lichao ; Kirkendall, Garrett
> > ; Grimes, Paul ; He,
> > Jiangang ; Andrew Fish 
> > 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  On Behalf Of Leif
> > > Lindholm
> > > Sent: Friday, September 30, 2022 9:09 AM
> > > To: devel@edk2.groups.io; Kinney, Michael D
> > > ; Chang, Abner ; Ni,
> > > Ray ; Attar, AbdulLateef (Abdul Lateef)
> > > ; Sunil V L 
> > > Cc: lichao ; Kirkendall, Garrett
> > > ; Grimes, Paul ; He,
> > > Jiangang ; Andrew Fish 
> > > 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.
> > > >
> > 

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

[Chang, Abner via groups.io]

[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 
> Sent: Saturday, October 1, 2022 2:52 AM
> To: devel@edk2.groups.io; quic_llind...@quicinc.com; Chang, Abner
> ; Ni, Ray ; Attar, AbdulLateef
> (Abdul Lateef) ; Sunil V L
> ; Kinney, Michael D 
> Cc: lichao ; Kirkendall, Garrett
> ; Grimes, Paul ; He,
> Jiangang ; Andrew Fish 
> 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  On Behalf Of Leif
> > Lindholm
> > Sent: Friday, September 30, 2022 9:09 AM
> > To: devel@edk2.groups.io; Kinney, Michael D
> > ; Chang, Abner ; Ni,
> > Ray ; Attar, AbdulLateef (Abdul Lateef)
> > ; Sunil V L 
> > Cc: lichao ; Kirkendall, Garrett
> > ; Grimes, Paul ; He,
> > Jiangang ; Andrew Fish 
> > 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 
> > >> Sent: Friday, September 30, 2022 12:11 AM
> > >> To: Ni, Ray ; Attar, AbdulLateef (Abdul Lateef)
> > >> ; Sunil V L ;
> > >> devel@edk2.groups.io; Kinney, Michael D
> > >> 
> > >> Cc: lichao ; Kirkendall, Garrett
> > >> ; Grimes, Paul ;
> > >> He, Jiangang ; Leif Lindholm
> > >> ; Andrew Fish 
> > >> Subject: RE: [edk2-devel] The principles of EDK2 module
> > >> reconstruction for archs
> > >>
> > >> [AMD Official Use Only - General]
> > >>
> > >> Thanks Ray, here are 

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 
Sent: Friday, September 30, 2022 12:11 AM
To: Ni, Ray ; Attar, AbdulLateef (Abdul Lateef) 
; Sunil V L
; devel@edk2.groups.io; Kinney, Michael D 

Cc: lichao ; Kirkendall, Garrett ; 
Grimes, Paul ; He,
Jiangang ; Leif Lindholm ; Andrew 
Fish 
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 
Sent: Thursday, September 29, 2022 3:42 PM
To: Attar, AbdulLateef (Abdul Lateef) ; Chang,
Abner ; Sunil V L ;
devel@edk2.groups.io
Cc: Kinney, Michael D ; lichao
; Kirkendall, Garrett ;
Grimes, Paul ; He, Jiangang
; Leif Lindholm ;
Andrew Fish 
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-
1124763311data=05%7C01%7CAbner.Chang%40amd.com%7Cd825e24
8625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82d994e183d%7C0
%7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
7C%7C%7Csdata=RXxgpbEr6ivbqP1R6%2B3Rxl%2ByJAnaUJuaYYKdfCH
8jo8%3Dreserved=0

We can discuss more in tomorrow's meeting.



-Original Message-
From: Attar, AbdulLateef (Abdul Lateef) 
Sent: Thursday, September 29, 2022 3:11 PM
To: Chang, Abner ; Sunil V L
; devel@edk2.groups.io; Ni, Ray

Cc: Kinney, Michael D ; lichao
; Kirkendall, Garrett
; Grimes, Paul ;

He,

Jiangang ; Leif Lindholm
; Andrew Fish 
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction
for archs

Hi Abner,
 Looks good to me.
Reviewed-by:  Abdul Lateef Attar 

Thanks
AbduL

-Original Message-
From: Chang, Abner 
Sent: 28 September 2022 20:31
To: Sunil V L ; devel@edk2.groups.io;
ray...@intel.com
Cc: Kinney, Michael D ; lichao
; Kirkendall, Garrett
; Grimes, Paul ;

He,

Jiangang ; Attar, AbdulLateef (Abdul Lateef)
; Leif Lindholm
; Andrew Fish 
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-

data=05%7C01%7CAbner.Chang%40amd.c



om%7Cd825e248625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82
d994e18



3d%7C0%7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJ
WIjoiMC4wLj



AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
7C%7C



mp;sdata=X4z9puj81nIGTqtMxC9igDZyBPOT6OTWSU%2BjoIowo%2BE%3D
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 
Sent: Wednesday, September 28, 2022 3:34 PM
To: 

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 
> Sent: Friday, September 30, 2022 12:11 AM
> To: Ni, Ray ; Attar, AbdulLateef (Abdul Lateef) 
> ; Sunil V L
> ; devel@edk2.groups.io; Kinney, Michael D 
> 
> Cc: lichao ; Kirkendall, Garrett 
> ; Grimes, Paul ; He,
> Jiangang ; Leif Lindholm ; 
> Andrew Fish 
> 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 
> > Sent: Thursday, September 29, 2022 3:42 PM
> > To: Attar, AbdulLateef (Abdul Lateef) ; Chang,
> > Abner ; Sunil V L ;
> > devel@edk2.groups.io
> > Cc: Kinney, Michael D ; lichao
> > ; Kirkendall, Garrett ;
> > Grimes, Paul ; He, Jiangang
> > ; Leif Lindholm ;
> > Andrew Fish 
> > 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-
> > 1124763311data=05%7C01%7CAbner.Chang%40amd.com%7Cd825e24
> > 8625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82d994e183d%7C0
> > %7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> > 7C%7C%7Csdata=RXxgpbEr6ivbqP1R6%2B3Rxl%2ByJAnaUJuaYYKdfCH
> > 8jo8%3Dreserved=0
> >
> > We can discuss more in tomorrow's meeting.
> >
> >
> > > -Original Message-
> > > From: Attar, AbdulLateef (Abdul Lateef) 
> > > Sent: Thursday, September 29, 2022 3:11 PM
> > > To: Chang, Abner ; Sunil V L
> > > ; devel@edk2.groups.io; Ni, Ray
> > > 
> > > Cc: Kinney, Michael D ; lichao
> > > ; Kirkendall, Garrett
> > > ; Grimes, Paul ;
> > He,
> > > Jiangang ; Leif Lindholm
> > > ; Andrew Fish 
> > > Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction
> > > for archs
> > >
> > > Hi Abner,
> > > Looks good to me.
> > > Reviewed-by:  Abdul Lateef Attar 
> > >
> > > Thanks
> > > AbduL
> > >
> > > -Original Message-
> > > From: Chang, Abner 
> > > Sent: 28 September 2022 20:31
> > > To: Sunil V L ; devel@edk2.groups.io;
> > > ray...@intel.com
> > > Cc: Kinney, Michael D ; lichao
> > > ; Kirkendall, Garrett
> > > ; Grimes, Paul ;
> > He,
> > > Jiangang ; Attar, AbdulLateef (Abdul Lateef)
> > > ; Leif Lindholm
> > > ; Andrew Fish 
> > > 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-
> > data=05%7C01%7CAbner.Chang%40amd.c
> > >
> > om%7Cd825e248625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82
> > d994e18
> > >
> > 3d%7C0%7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJ
> > WIjoiMC4wLj
> > >
> > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> > 7C%7C
> > >
> > mp;sdata=X4z9puj81nIGTqtMxC9igDZyBPOT6OTWSU%2BjoIowo%2BE%3D
> > 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
> 

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

[Chang, Abner via groups.io]

[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 
> Sent: Thursday, September 29, 2022 3:42 PM
> To: Attar, AbdulLateef (Abdul Lateef) ; Chang,
> Abner ; Sunil V L ;
> devel@edk2.groups.io
> Cc: Kinney, Michael D ; lichao
> ; Kirkendall, Garrett ;
> Grimes, Paul ; He, Jiangang
> ; Leif Lindholm ;
> Andrew Fish 
> 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-
> 1124763311data=05%7C01%7CAbner.Chang%40amd.com%7Cd825e24
> 8625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82d994e183d%7C0
> %7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> 7C%7C%7Csdata=RXxgpbEr6ivbqP1R6%2B3Rxl%2ByJAnaUJuaYYKdfCH
> 8jo8%3Dreserved=0
> 
> We can discuss more in tomorrow's meeting.
> 
> 
> > -Original Message-
> > From: Attar, AbdulLateef (Abdul Lateef) 
> > Sent: Thursday, September 29, 2022 3:11 PM
> > To: Chang, Abner ; Sunil V L
> > ; devel@edk2.groups.io; Ni, Ray
> > 
> > Cc: Kinney, Michael D ; lichao
> > ; Kirkendall, Garrett
> > ; Grimes, Paul ;
> He,
> > Jiangang ; Leif Lindholm
> > ; Andrew Fish 
> > Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction
> > for archs
> >
> > Hi Abner,
> > Looks good to me.
> > Reviewed-by:  Abdul Lateef Attar 
> >
> > Thanks
> > AbduL
> >
> > -Original Message-
> > From: Chang, Abner 
> > Sent: 28 September 2022 20:31
> > To: Sunil V L ; devel@edk2.groups.io;
> > ray...@intel.com
> > Cc: Kinney, Michael D ; lichao
> > ; Kirkendall, Garrett
> > ; Grimes, Paul ;
> He,
> > Jiangang ; Attar, AbdulLateef (Abdul Lateef)
> > ; Leif Lindholm
> > ; Andrew Fish 
> > 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-
> data=05%7C01%7CAbner.Chang%40amd.c
> >
> om%7Cd825e248625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82
> d994e18
> >
> 3d%7C0%7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLj
> >
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> 7C%7C
> >
> mp;sdata=X4z9puj81nIGTqtMxC9igDZyBPOT6OTWSU%2BjoIowo%2BE%3D
> 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 
> > > Sent: Wednesday, September 28, 2022 3:34 PM
> > > To: devel@edk2.groups.io; ray...@intel.com
> > > Cc: Chang, Abner ; Kinney, Michael D
> > > ; lichao ;
> > > Kirkendall, Garrett ; Grimes, Paul
> > > ; He, Jiangang ; Attar,
> > > AbdulLateef (Abdul Lateef) ; Leif
> > > Lindholm ; Andrew Fish 
> > > 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 +, 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 

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

[Chang, Abner via groups.io]

[AMD Official Use Only - General]



> -Original Message-
> From: Sunil V L 
> Sent: Thursday, September 29, 2022 11:22 PM
> To: Chang, Abner 
> Cc: devel@edk2.groups.io; ray...@intel.com; Kinney, Michael D
> ; lichao ; Kirkendall,
> Garrett ; Grimes, Paul
> ; He, Jiangang ; Attar,
> AbdulLateef (Abdul Lateef) ; Leif Lindholm
> ; Andrew Fish 
> 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 +, 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-
> PRdata=
> >
> 05%7C01%7CAbner.Chang%40amd.com%7Cb644f4b61bbd4e096c2308daa22e
> 6703%7C3
> >
> dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638000617445410044%7C
> Unknown
> >
> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLCJ
> >
> XVCI6Mn0%3D%7C3000%7C%7C%7Csdata=wRnI%2Br4Dunydf77gSClb
> 6ghHuY24Qs
> > LrZTiPqc7pP1I%3Dreserved=0
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Fchangab%2Fedk2-platforms%2Fcommits%2FRISC-V-
> MIGRATION-EDK2-PL
> >
> ATFORMdata=05%7C01%7CAbner.Chang%40amd.com%7Cb644f4b61b
> bd4e096c23
> >
> 08daa22e6703%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63800
> 0617445
> >
> 410044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
> luMzIiLCJ
> >
> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=5T2PHJOj
> %2Bk6Mmu
> > zNn0vsELm0raYiIDiI1X%2FekgZt6ls%3Dreserved=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
> b54d1f4181a6data=05%7C01%7CAbner.Chang%40amd.com%7Cb644f4
> b61bbd4e096c2308daa22e6703%7C3dd8961fe4884e608e11a82d994e183d%7C
> 0%7C0%7C638000617445566273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> %7C%7C%7Csdata=2TRD8pySU%2FIhz7ttFwdCHtPpl6JM0YSp%2BZjvo5
> %2FEEZ4%3Dreserved=0
> 
> IMO, RB tag should be removed and should be reviewed fresh when it is
> being added to edk2 repo.
> 
> Thanks
> Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94543): https://edk2.groups.io/g/devel/message/94543
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]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Attar, AbdulLateef (Abdul Lateef) via groups.io]

Hi Abner,
Looks good to me.
Reviewed-by:  Abdul Lateef Attar 

Thanks
AbduL

-Original Message-
From: Chang, Abner  
Sent: 28 September 2022 20:31
To: Sunil V L ; devel@edk2.groups.io; ray...@intel.com
Cc: Kinney, Michael D ; lichao 
; Kirkendall, Garrett ; Grimes, 
Paul ; He, Jiangang ; Attar, 
AbdulLateef (Abdul Lateef) ; Leif Lindholm 
; Andrew Fish 
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 
> Sent: Wednesday, September 28, 2022 3:34 PM
> To: devel@edk2.groups.io; ray...@intel.com
> Cc: Chang, Abner ; Kinney, Michael D 
> ; lichao ; Kirkendall, 
> Garrett ; Grimes, Paul 
> ; He, Jiangang ; Attar, 
> AbdulLateef (Abdul Lateef) ; Leif Lindholm 
> ; Andrew Fish 
> 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 +, 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
> data=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08d
> aa123e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947
> 2732494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csd
> ata=Vq6pJLnn8yJrJhFZn7LfLbZzrtpG4n1VLWgAil6J38U%3Dreserved=0
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Ftianocore%2Fedk2-
> staging%2Fcommit%2F7fccf92a97a6d0618a20f1060e78b3687906da
> ta=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08daa1
> 23e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947273
> 2494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata
> =xFmvUv58vh4AUAM17Qy9G5jZWFZlK2Ozt3njpG1e8%2BY%3Dreserv
> 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 (#94534): https://edk2.groups.io/g/devel/message/94534
Mute This Topic: https://groups.io/mt/93872791/21656
Group Owner: 

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

[Sunil V L]

On Thu, Sep 29, 2022 at 02:54:05PM +, 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


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94523): https://edk2.groups.io/g/devel/message/94523
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]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Chang, Abner via groups.io]

[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  On Behalf Of Ni, Ray
> via groups.io
> Sent: Thursday, September 29, 2022 3:48 PM
> To: devel@edk2.groups.io; suni...@ventanamicro.com
> Cc: Chang, Abner ; Kinney, Michael D
> ; lichao ; Kirkendall,
> Garrett ; Grimes, Paul
> ; He, Jiangang ; Attar,
> AbdulLateef (Abdul Lateef) ; Leif Lindholm
> ; Andrew Fish 
> 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  On Behalf Of Sunil V
> > L
> > Sent: Wednesday, September 28, 2022 3:34 PM
> > To: devel@edk2.groups.io; Ni, Ray 
> > Cc: abner.ch...@amd.com; Kinney, Michael D
> > ; lichao ; Kirkendall,
> > Garrett ; Grimes, Paul
> > ; He, Jiangang ; Attar,
> > AbdulLateef (Abdul Lateef) ; Leif Lindholm
> > ; Andrew Fish 
> > Subject: Re: [edk2-devel] The principles of EDK2 module reconstruction
> > for archs
> >
> > On Wed, Sep 28, 2022 at 03:33:45AM +, 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-
> 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%3Dreserv
> ed=0
> > staging/commit/bba1a11be47dd091734e185afbed73ea75708749
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Ftianocore%2Fedk2-
> 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%3Dreserv
> ed=0
> > staging/commit/7fccf92a97a6d0618a20f1060e78b3687906
> >
> > 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 (#94522): https://edk2.groups.io/g/devel/message/94522
Mute This Topic: https://groups.io/mt/93872791/21656
Group Owner: devel+ow...@edk2.groups.io

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  On Behalf Of Sunil V L
> Sent: Wednesday, September 28, 2022 3:34 PM
> To: devel@edk2.groups.io; Ni, Ray 
> Cc: abner.ch...@amd.com; Kinney, Michael D
> ; lichao ; Kirkendall,
> Garrett ; Grimes, Paul
> ; He, Jiangang ; Attar,
> AbdulLateef (Abdul Lateef) ; Leif Lindholm
> ; Andrew Fish 
> Subject: Re: [edk2-devel] The principles of EDK2 module reconstruction for
> archs
> 
> On Wed, Sep 28, 2022 at 03:33:45AM +, 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/7fccf92a97a6d0618a20f1060e78b3687906
> 
> 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 (#94510): https://edk2.groups.io/g/devel/message/94510
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]
-=-=-=-=-=-=-=-=-=-=-=-

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) 
> Sent: Thursday, September 29, 2022 3:11 PM
> To: Chang, Abner ; Sunil V L
> ; devel@edk2.groups.io; Ni, Ray
> 
> Cc: Kinney, Michael D ; lichao
> ; Kirkendall, Garrett ;
> Grimes, Paul ; He, Jiangang
> ; Leif Lindholm ;
> Andrew Fish 
> Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for
> archs
> 
> Hi Abner,
> Looks good to me.
> Reviewed-by:  Abdul Lateef Attar 
> 
> Thanks
> AbduL
> 
> -Original Message-
> From: Chang, Abner 
> Sent: 28 September 2022 20:31
> To: Sunil V L ; devel@edk2.groups.io;
> ray...@intel.com
> Cc: Kinney, Michael D ; lichao
> ; Kirkendall, Garrett ;
> Grimes, Paul ; He, Jiangang
> ; Attar, AbdulLateef (Abdul Lateef)
> ; Leif Lindholm ;
> Andrew Fish 
> 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 
> > Sent: Wednesday, September 28, 2022 3:34 PM
> > To: devel@edk2.groups.io; ray...@intel.com
> > Cc: Chang, Abner ; Kinney, Michael D
> > ; lichao ; Kirkendall,
> > Garrett ; Grimes, Paul
> > ; He, Jiangang ; Attar,
> > AbdulLateef (Abdul Lateef) ; Leif Lindholm
> > ; Andrew Fish 
> > 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 +, 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
> >
> data=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08d
> >
> aa123e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947
> >
> 2732494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> >
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csd
> >
> ata=Vq6pJLnn8yJrJhFZn7LfLbZzrtpG4n1VLWgAil6J38U%3Dreserved=0
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Ftianocore%2Fedk2-
> >
> staging%2Fcommit%2F7fccf92a97a6d0618a20f1060e78b3687906da
> >
> ta=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08daa1
> >
> 23e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947273
> >
> 2494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> >
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata
> >
> =xFmvUv58vh4AUAM17Qy9G5jZWFZlK2Ozt3njpG1e8%2BY%3Dreserv
> > 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 

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

[Chang, Abner via groups.io]

[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 
> Sent: Wednesday, September 28, 2022 3:34 PM
> To: devel@edk2.groups.io; ray...@intel.com
> Cc: Chang, Abner ; Kinney, Michael D
> ; lichao ; Kirkendall,
> Garrett ; Grimes, Paul
> ; He, Jiangang ; Attar,
> AbdulLateef (Abdul Lateef) ; Leif Lindholm
> ; Andrew Fish 
> 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 +, 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
> data=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08d
> aa123e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947
> 2732494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csd
> ata=Vq6pJLnn8yJrJhFZn7LfLbZzrtpG4n1VLWgAil6J38U%3Dreserved=0
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Ftianocore%2Fedk2-
> staging%2Fcommit%2F7fccf92a97a6d0618a20f1060e78b3687906da
> ta=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08daa1
> 23e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947273
> 2494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata
> =xFmvUv58vh4AUAM17Qy9G5jZWFZlK2Ozt3njpG1e8%2BY%3Dreserv
> 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 

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

This is the draft version to community 

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

[Sunil V L]

On Wed, Sep 28, 2022 at 03:33:45AM +, 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/7fccf92a97a6d0618a20f1060e78b3687906

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 (#94457): https://edk2.groups.io/g/devel/message/94457
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]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Chang, Abner via groups.io]

[AMD Official Use Only - General]



From: Ni, Ray 
Sent: Wednesday, September 28, 2022 1:43 PM
To: devel@edk2.groups.io; Chang, Abner 
Cc: Kinney, Michael D ; Sunil V L 
; lichao ; Kirkendall, Garrett 
; Grimes, Paul ; He, Jiangang 
; Attar, AbdulLateef (Abdul Lateef) 
; Leif Lindholm ; Andrew 
Fish 
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  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>> On Behalf Of Chang, Abner 
via groups.io
Sent: Wednesday, September 28, 2022 12:31 PM
To: devel@edk2.groups.io; Ni, Ray 
mailto:ray...@intel.com>>
Cc: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; Sunil V L 
mailto:suni...@ventanamicro.com>>; lichao 
mailto:lic...@loongson.cn>>; Kirkendall, Garrett 
mailto:garrett.kirkend...@amd.com>>; Grimes, Paul 
mailto:paul.gri...@amd.com>>; He, Jiangang 
mailto:jiangang...@amd.com>>; Attar, AbdulLateef (Abdul 
Lateef) mailto:abdullateef.at...@amd.com>>; Leif 
Lindholm mailto:quic_llind...@quicinc.com>>; Andrew 
Fish mailto:af...@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>> On Behalf Of Ni, Ray via 
groups.io
Sent: Wednesday, September 28, 2022 11:34 AM
To: devel@edk2.groups.io; Chang, Abner 
mailto:abner.ch...@amd.com>>
Cc: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; Sunil V L 
mailto:suni...@ventanamicro.com>>; lichao 
mailto:lic...@loongson.cn>>; Kirkendall, Garrett 
mailto:garrett.kirkend...@amd.com>>; Grimes, Paul 
mailto:paul.gri...@amd.com>>; He, Jiangang 
mailto:jiangang...@amd.com>>; Attar, AbdulLateef (Abdul 
Lateef) mailto:abdullateef.at...@amd.com>>; Leif 
Lindholm mailto:quic_llind...@quicinc.com>>; Andrew 
Fish mailto: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.

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.

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

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

[Ni, Ray]

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  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  On Behalf Of Chang, Abner via 
groups.io
Sent: Wednesday, September 28, 2022 12:31 PM
To: devel@edk2.groups.io; Ni, Ray 
Cc: Kinney, Michael D ; Sunil V L 
; lichao ; Kirkendall, Garrett 
; Grimes, Paul ; He, Jiangang 
; Attar, AbdulLateef (Abdul Lateef) 
; Leif Lindholm ; Andrew 
Fish 
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>> On Behalf Of Ni, Ray via 
groups.io
Sent: Wednesday, September 28, 2022 11:34 AM
To: devel@edk2.groups.io; Chang, Abner 
mailto:abner.ch...@amd.com>>
Cc: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; Sunil V L 
mailto:suni...@ventanamicro.com>>; lichao 
mailto:lic...@loongson.cn>>; Kirkendall, Garrett 
mailto:garrett.kirkend...@amd.com>>; Grimes, Paul 
mailto:paul.gri...@amd.com>>; He, Jiangang 
mailto:jiangang...@amd.com>>; Attar, AbdulLateef (Abdul 
Lateef) mailto:abdullateef.at...@amd.com>>; Leif 
Lindholm mailto:quic_llind...@quicinc.com>>; Andrew 
Fish mailto: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.

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.

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

.*

 *   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 

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

[Chang, Abner via groups.io]

[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 
Sent: Wednesday, September 28, 2022 11:56 AM
To: Kinney, Michael D ; devel@edk2.groups.io; 
Chang, Abner 
Cc: Sunil V L ; lichao ; 
Kirkendall, Garrett ; Grimes, Paul 
; He, Jiangang ; Attar, AbdulLateef 
(Abdul Lateef) ; Leif Lindholm 
; Andrew Fish 
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 
mailto:michael.d.kin...@intel.com>>
Sent: Saturday, September 24, 2022 2:01 AM
To: devel@edk2.groups.io; 
abner.ch...@amd.com; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Cc: Ni, Ray mailto:ray...@intel.com>>; Sunil V L 
mailto:suni...@ventanamicro.com>>; lichao 
mailto:lic...@loongson.cn>>; Kirkendall, Garrett 
mailto:garrett.kirkend...@amd.com>>; Grimes, Paul 
mailto:paul.gri...@amd.com>>; He, Jiangang 
mailto:jiangang...@amd.com>>; Attar, AbdulLateef (Abdul 
Lateef) mailto:abdullateef.at...@amd.com>>; Leif 
Lindholm mailto:quic_llind...@quicinc.com>>; Andrew 
Fish mailto:af...@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:   Pkg
Package DEC File Name: 
Pkg.dec

REQUIRED   *

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

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

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

Library Instance Directory Name:

Library Instance INF File Name:   
.inf

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

Source File Paths within a Library/Module instance
  .c
  .h
  /.c
  /.h
  /.nasm
  /.S

   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/.   So an 
enhancement to the above Source File Paths would be:

Source File Paths within a Library/Module instance
  .c
  .h
  /.c
  /.h
  /.nasm
  /.S
  

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

[Chang, Abner via groups.io]

[AMD Official Use Only - General]



From: 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 
Cc: Kinney, Michael D ; Sunil V L 
; lichao ; Kirkendall, Garrett 
; Grimes, Paul ; He, Jiangang 
; Attar, AbdulLateef (Abdul Lateef) 
; Leif Lindholm ; Andrew 
Fish 
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.

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

.*

 *   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 

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

[Ni, Ray]

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 
Sent: Saturday, September 24, 2022 2:01 AM
To: devel@edk2.groups.io; abner.ch...@amd.com; Kinney, Michael D 

Cc: Ni, Ray ; Sunil V L ; lichao 
; Kirkendall, Garrett ; Grimes, 
Paul ; He, Jiangang ; Attar, 
AbdulLateef (Abdul Lateef) ; Leif Lindholm 
; Andrew Fish 
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:   Pkg
Package DEC File Name: 
Pkg.dec

REQUIRED   *

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

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

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

Library Instance Directory Name:

Library Instance INF File Name:   
.inf

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

Source File Paths within a Library/Module instance
  .c
  .h
  /.c
  /.h
  /.nasm
  /.S

   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/.   So an 
enhancement to the above Source File Paths would be:

Source File Paths within a Library/Module instance
  .c
  .h
  /.c
  /.h
  /.nasm
  /.S
  //.c
  //.h
  //.nasm
  //.S

   OPTIONAL   Ia32, X64, 
Arm, AArch64, RiscV64, LoongArch64, Ebc, X86
 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>> On Behalf Of Chang, Abner 
via groups.io
Sent: Friday, September 23, 2022 8:39 AM
To: devel@edk2.groups.io
Cc: Ni, Ray mailto:ray...@intel.com>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; Sunil V L 
mailto:suni...@ventanamicro.com>>; lichao 
mailto:lic...@loongson.cn>>; Kirkendall, Garrett 
mailto:garrett.kirkend...@amd.com>>; Grimes, Paul 
mailto:paul.gri...@amd.com>>; He, Jiangang 
mailto:jiangang...@amd.com>>; Attar, AbdulLateef (Abdul 
Lateef) mailto:abdullateef.at...@amd.com>>; Leif 
Lindholm mailto:quic_llind...@quicinc.com>>; Andrew 
Fish mailto:af...@apple.com>>
Subject: [edk2-devel] The principles of EDK2 module reconstruction for archs


[AMD Official Use Only - General]

All,
Today in 

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

[Ni, Ray]

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

.*

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

 *   The file naming for the common implementation

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 

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

[Chang, Abner via groups.io]

[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 
Sent: Monday, September 26, 2022 11:45 PM
To: devel@edk2.groups.io; Chang, Abner ; Kinney, Michael D 

Cc: Ni, Ray ; Sunil V L ; lichao 
; Kirkendall, Garrett ; Grimes, 
Paul ; He, Jiangang ; Attar, 
AbdulLateef (Abdul Lateef) ; Leif Lindholm 
; Andrew Fish ; Kinney, Michael D 

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>> On Behalf Of Chang, Abner 
via groups.io
Sent: Monday, September 26, 2022 12:34 AM
To: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; 
devel@edk2.groups.io
Cc: Ni, Ray mailto:ray...@intel.com>>; Sunil V L 
mailto:suni...@ventanamicro.com>>; lichao 
mailto:lic...@loongson.cn>>; Kirkendall, Garrett 
mailto:garrett.kirkend...@amd.com>>; Grimes, Paul 
mailto:paul.gri...@amd.com>>; He, Jiangang 
mailto:jiangang...@amd.com>>; Attar, AbdulLateef (Abdul 
Lateef) mailto:abdullateef.at...@amd.com>>; Leif 
Lindholm mailto:quic_llind...@quicinc.com>>; Andrew 
Fish mailto:af...@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 
mailto:michael.d.kin...@intel.com>>
Sent: Saturday, September 24, 2022 2:01 AM
To: devel@edk2.groups.io; Chang, Abner 
mailto:abner.ch...@amd.com>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Cc: Ni, Ray mailto:ray...@intel.com>>; Sunil V L 
mailto:suni...@ventanamicro.com>>; lichao 
mailto:lic...@loongson.cn>>; Kirkendall, Garrett 
mailto:garrett.kirkend...@amd.com>>; Grimes, Paul 
mailto:paul.gri...@amd.com>>; He, Jiangang 
mailto:jiangang...@amd.com>>; Attar, AbdulLateef (Abdul 
Lateef) mailto:abdullateef.at...@amd.com>>; Leif 
Lindholm 

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

[Chang, Abner via groups.io]

[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 
Sent: Saturday, September 24, 2022 2:01 AM
To: devel@edk2.groups.io; Chang, Abner ; Kinney, Michael D 

Cc: Ni, Ray ; Sunil V L ; lichao 
; Kirkendall, Garrett ; Grimes, 
Paul ; He, Jiangang ; Attar, 
AbdulLateef (Abdul Lateef) ; Leif Lindholm 
; Andrew Fish 
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:  Pkg
Package DEC File Name:
Pkg.dec

   REQUIRED   *

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

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

Library Instance Directory Name: 

Library Instance INF File Name:  
.inf

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

Source File Paths within a Library/Module instance
 .c
 .h
 /.c
 /.h
 /.nasm
 /.S

  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