<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="ProgId" content="Word.Document"> <meta name="Generator" content="Microsoft Word 15"> <meta name="Originator" content="Microsoft Word 15"> <link rel="File-List" href="cid:filelist.xml@01D8DD73.9DBDF880"><link rel="Edit-Time-Data" href="cid:editdata.mso"><style></style> </head> <body lang="EN-US" link="blue" vlink="purple" style="tab-interval:.5in;word-wrap:break-word"> <div class="WordSection1"> I do not have a strong opinion either way. <o:p></o:p> <o:p> </o:p> Some searching indicates there is some debate between use of spaces, underscores, and dashes in filenames.<o:p></o:p> <o:p> </o:p> The filename/dirname requirements for EDK II allow ‘_’ and ‘-‘ as long as they are not the first or last character. Spaces ‘ ‘ are not allowed.<o:p></o:p> <o:p> </o:p> [A-Za-z][_A-Za-z0-9-]*[A-Za-z0-9]+<o:p></o:p> <o:p> </o:p> Mike<o:p></o:p> <o:p> </o:p> <div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> From: Chang, Abner <Abner.Chang@amd.com> Sent: Monday, October 10, 2022 7:21 PM To: Ni, Ray <ray.ni@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io; quic_llindhol@quicinc.com; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com>; Sunil V L <sunilvl@ventanamicro.com> Cc: lichao <lichao@loongson.cn>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com>; Grimes, Paul <Paul.Grimes@amd.com>; He, Jiangang <Jiangang.He@amd.com>; Andrew Fish <afish@apple.com> Subject: Re: [edk2-devel] The principles of EDK2 module reconstruction for archs<o:p></o:p> </div> </div> <o:p> </o:p> [AMD Official Use Only - General]<o:p></o:p> <o:p> </o:p> <div> <div> Removing '_' seems make the folder hard to read, but not too bad to me though. I am fine with removing '_'. <o:p></o:p> </div> <div> Leif and Mike, how do you think?<o:p></o:p> </div> <div> <o:p> </o:p> </div> <div> Ex:<o:p></o:p> </div> <div> Riscv64Ia32X64 compares Riscv64_Ia32_X64.<o:p></o:p> </div> <div> ArmAArch64 compares to Arm_AArch64.<o:p></o:p> </div> <div> <o:p> </o:p> </div> <div> Abner<o:p></o:p> </div> <div id="ms-outlook-mobile-signature"> <div> <o:p> </o:p> </div> Get <a href="https://aka.ms/AAb9ysg"> Outlook for Android</a><o:p></o:p> </div> <div class="MsoNormal" align="center" style="text-align:center"> <hr size="2" width="98%" align="center"> </div> <div id="divRplyFwdMsg"> From: Ni, Ray <<a href="mailto:ray.ni@intel.com">ray.ni@intel.com</a>> Sent: Tuesday, October 11, 2022 9:51:24 AM To: Chang, Abner <<a href="mailto:Abner.Chang@amd.com">Abner.Chang@amd.com</a>>; Kinney, Michael D <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>>; <a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a> <<a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a>>; <a href="mailto:quic_llindhol@quicinc.com">quic_llindhol@quicinc.com</a> <<a href="mailto:quic_llindhol@quicinc.com">quic_llindhol@quicinc.com</a>>; Attar, AbdulLateef (Abdul Lateef) <<a href="mailto:AbdulLateef.Attar@amd.com">AbdulLateef.Attar@amd.com</a>>; Sunil V L <<a href="mailto:sunilvl@ventanamicro.com">sunilvl@ventanamicro.com</a>> Cc: lichao <<a href="mailto:lichao@loongson.cn">lichao@loongson.cn</a>>; Kirkendall, Garrett <<a href="mailto:Garrett.Kirkendall@amd.com">Garrett.Kirkendall@amd.com</a>>; Grimes, Paul <<a href="mailto:Paul.Grimes@amd.com">Paul.Grimes@amd.com</a>>; He, Jiangang <<a href="mailto:Jiangang.He@amd.com">Jiangang.He@amd.com</a>>; Andrew Fish <<a href="mailto:afish@apple.com">afish@apple.com</a>> Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for archs <o:p></o:p> <div> <o:p></o:p> </div> </div> <div> <div> 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. <a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F94912%3Fp%3D%252C%252C%252C20%252C0%252C0%252C0%253A%253Arecentpostdate%252Fsticky%252C%252CUefiCpuPkg%252FCpuTimerLib%252C20%252C2%252C0%252C94233015&data=05%7C01%7CAbner.Chang%40amd.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5wOiTArZyySLos4A%2FQHOC3gryUIZ8K4SgNxeTwfANMY%3D&reserved=0">https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F94912%3Fp%3D%252C%252C%252C20%252C0%252C0%252C0%253A%253Arecentpostdate%252Fsticky%252C%252CUefiCpuPkg%252FCpuTimerLib%252C20%252C2%252C0%252C94233015&data=05%7C01%7CAbner.Chang%40amd.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5wOiTArZyySLos4A%2FQHOC3gryUIZ8K4SgNxeTwfANMY%3D&reserved=0</a> Thanks, Ray > -----Original Message----- > From: Chang, Abner <<a href="mailto:Abner.Chang@amd.com">Abner.Chang@amd.com</a>> > Sent: Thursday, October 6, 2022 4:37 PM > To: Kinney, Michael D <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>>; <a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a>; > <a href="mailto:quic_llindhol@quicinc.com">quic_llindhol@quicinc.com</a>; Ni, Ray <<a href="mailto:ray.ni@intel.com">ray.ni@intel.com</a>>; Attar, AbdulLateef > (Abdul Lateef) <<a href="mailto:AbdulLateef.Attar@amd.com">AbdulLateef.Attar@amd.com</a>>; Sunil V L > <<a href="mailto:sunilvl@ventanamicro.com">sunilvl@ventanamicro.com</a>> > Cc: lichao <<a href="mailto:lichao@loongson.cn">lichao@loongson.cn</a>>; Kirkendall, Garrett > <<a href="mailto:Garrett.Kirkendall@amd.com">Garrett.Kirkendall@amd.com</a>>; Grimes, Paul <<a href="mailto:Paul.Grimes@amd.com">Paul.Grimes@amd.com</a>>; He, > Jiangang <<a href="mailto:Jiangang.He@amd.com">Jiangang.He@amd.com</a>>; Andrew Fish <<a href="mailto:afish@apple.com">afish@apple.com</a>> > 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. > <a href="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%7C&sdata=i5RSe41cuzD48VB32KeG0M3Vp7T%2FEqe3ncKNfGCjfIU%3D&reserved=0"> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchangab%2Ftianocore.github.io%2Fwiki%2FThe-Guidelines-of-&data=05%7C01%7CAbner.Chang%40amd.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=i5RSe41cuzD48VB32KeG0M3Vp7T%2FEqe3ncKNfGCjfIU%3D&reserved=0</a> > 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 <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>>; > <a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a>; > > <a href="mailto:quic_llindhol@quicinc.com">quic_llindhol@quicinc.com</a>; Ni, Ray <<a href="mailto:ray.ni@intel.com">ray.ni@intel.com</a>>; Attar, AbdulLateef > > (Abdul Lateef) <<a href="mailto:AbdulLateef.Attar@amd.com">AbdulLateef.Attar@amd.com</a>>; Sunil V L > > <<a href="mailto:sunilvl@ventanamicro.com">sunilvl@ventanamicro.com</a>> > > Cc: lichao <<a href="mailto:lichao@loongson.cn">lichao@loongson.cn</a>>; Kirkendall, Garrett > > <<a href="mailto:Garrett.Kirkendall@amd.com">Garrett.Kirkendall@amd.com</a>>; Grimes, Paul <<a href="mailto:Paul.Grimes@amd.com">Paul.Grimes@amd.com</a>>; > He, > > Jiangang <<a href="mailto:Jiangang.He@amd.com">Jiangang.He@amd.com</a>>; Andrew Fish <<a href="mailto:afish@apple.com">afish@apple.com</a>> > > Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for > > archs > > > > [AMD Official Use Only - General] > > > > PR updated > > <a href="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%7C&sdata=YDYXODgrQhuLlP8DTsLr%2F4ct2JH3aw8y2SPg8tk5fgg%3D&reserved=0"> 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%7C&sdata=YDYXODgrQhuLlP8DTsLr%2F4ct2JH3aw8y2SPg8tk5fgg%3D&reserved=0</a> > > CCodingStandardsSpecification/pull/2/commits. Please check it. > > > > Thanks > > Abner > > > > > -----Original Message----- > > > From: Kinney, Michael D <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>> > > > Sent: Tuesday, October 4, 2022 10:18 PM > > > To: Chang, Abner <<a href="mailto:Abner.Chang@amd.com">Abner.Chang@amd.com</a>>; <a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a>; > > > <a href="mailto:quic_llindhol@quicinc.com">quic_llindhol@quicinc.com</a>; Ni, Ray <<a href="mailto:ray.ni@intel.com">ray.ni@intel.com</a>>; Attar, > > > AbdulLateef (Abdul Lateef) <<a href="mailto:AbdulLateef.Attar@amd.com">AbdulLateef.Attar@amd.com</a>>; Sunil V L > > > <<a href="mailto:sunilvl@ventanamicro.com">sunilvl@ventanamicro.com</a>>; Kinney, Michael D > > > <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>> > > > Cc: lichao <<a href="mailto:lichao@loongson.cn">lichao@loongson.cn</a>>; Kirkendall, Garrett > > > <<a href="mailto:Garrett.Kirkendall@amd.com">Garrett.Kirkendall@amd.com</a>>; Grimes, Paul <<a href="mailto:Paul.Grimes@amd.com">Paul.Grimes@amd.com</a>>; > > He, > > > Jiangang <<a href="mailto:Jiangang.He@amd.com">Jiangang.He@amd.com</a>>; Andrew Fish <<a href="mailto:afish@apple.com">afish@apple.com</a>> > > > 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 <<a href="mailto:Abner.Chang@amd.com">Abner.Chang@amd.com</a>> > > > > Sent: Tuesday, October 4, 2022 7:05 AM > > > > To: Kinney, Michael D <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>>; > > > > <a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a>; <a href="mailto:quic_llindhol@quicinc.com"> quic_llindhol@quicinc.com</a>; Ni, Ray > > > > <<a href="mailto:ray.ni@intel.com">ray.ni@intel.com</a>>; Attar, AbdulLateef (Abdul Lateef) > > > > <<a href="mailto:AbdulLateef.Attar@amd.com">AbdulLateef.Attar@amd.com</a>>; Sunil V L <<a href="mailto:sunilvl@ventanamicro.com">sunilvl@ventanamicro.com</a>> > > > > Cc: lichao <<a href="mailto:lichao@loongson.cn">lichao@loongson.cn</a>>; Kirkendall, Garrett > > > > <<a href="mailto:Garrett.Kirkendall@amd.com">Garrett.Kirkendall@amd.com</a>>; Grimes, Paul > <<a href="mailto:Paul.Grimes@amd.com">Paul.Grimes@amd.com</a>>; > > > > He, Jiangang <<a href="mailto:Jiangang.He@amd.com">Jiangang.He@amd.com</a>>; Andrew Fish > <<a href="mailto:afish@apple.com">afish@apple.com</a>> > > > > Subject: RE: [edk2-devel] The principles of EDK2 module > > > > reconstruction for archs > > > > > > > > [AMD Official Use Only - General] > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Kinney, Michael D <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>> > > > > > Sent: Tuesday, October 4, 2022 12:54 AM > > > > > To: <a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a>; Chang, Abner <<a href="mailto:Abner.Chang@amd.com">Abner.Chang@amd.com</a>>; > > > > > <a href="mailto:quic_llindhol@quicinc.com">quic_llindhol@quicinc.com</a>; Ni, Ray <<a href="mailto:ray.ni@intel.com">ray.ni@intel.com</a>>; Attar, > > > > > AbdulLateef (Abdul Lateef) <<a href="mailto:AbdulLateef.Attar@amd.com">AbdulLateef.Attar@amd.com</a>>; Sunil V L > > > > > <<a href="mailto:sunilvl@ventanamicro.com">sunilvl@ventanamicro.com</a>>; Kinney, Michael D > > > > > <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>> > > > > > Cc: lichao <<a href="mailto:lichao@loongson.cn">lichao@loongson.cn</a>>; Kirkendall, Garrett > > > > > <<a href="mailto:Garrett.Kirkendall@amd.com">Garrett.Kirkendall@amd.com</a>>; Grimes, Paul > > <<a href="mailto:Paul.Grimes@amd.com">Paul.Grimes@amd.com</a>>; > > > > > He, Jiangang <<a href="mailto:Jiangang.He@amd.com">Jiangang.He@amd.com</a>>; Andrew Fish > > <<a href="mailto:afish@apple.com">afish@apple.com</a>> > > > > > 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: <a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a> <<a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a>> On Behalf Of > > > > > > Chang, Abner via groups.io > > > > > > Sent: Sunday, October 2, 2022 10:37 PM > > > > > > To: Kinney, Michael D <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>>; > > > > > > <a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a>; <a href="mailto:quic_llindhol@quicinc.com"> quic_llindhol@quicinc.com</a>; Ni, Ray > > > > > > <<a href="mailto:ray.ni@intel.com">ray.ni@intel.com</a>>; Attar, AbdulLateef (Abdul Lateef) > > > > > > <<a href="mailto:AbdulLateef.Attar@amd.com">AbdulLateef.Attar@amd.com</a>>; Sunil V L > > > > > > <<a href="mailto:sunilvl@ventanamicro.com">sunilvl@ventanamicro.com</a>> > > > > > > Cc: lichao <<a href="mailto:lichao@loongson.cn">lichao@loongson.cn</a>>; Kirkendall, Garrett > > > > > > <<a href="mailto:Garrett.Kirkendall@amd.com">Garrett.Kirkendall@amd.com</a>>; Grimes, Paul > > > > > > <<a href="mailto:Paul.Grimes@amd.com">Paul.Grimes@amd.com</a>>; > > > > > He, > > > > > > Jiangang <<a href="mailto:Jiangang.He@amd.com">Jiangang.He@amd.com</a>>; Andrew Fish <<a href="mailto:afish@apple.com">afish@apple.com</a>> > > > > > > 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 <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>> > > > > > > > Sent: Monday, October 3, 2022 1:18 PM > > > > > > > To: Chang, Abner <<a href="mailto:Abner.Chang@amd.com">Abner.Chang@amd.com</a>>; > > <a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a>; > > > > > > > <a href="mailto:quic_llindhol@quicinc.com">quic_llindhol@quicinc.com</a>; Ni, Ray <<a href="mailto:ray.ni@intel.com">ray.ni@intel.com</a>>; Attar, > > > > > > > AbdulLateef (Abdul Lateef) <<a href="mailto:AbdulLateef.Attar@amd.com">AbdulLateef.Attar@amd.com</a>>; Sunil > > > > > > > V L <<a href="mailto:sunilvl@ventanamicro.com">sunilvl@ventanamicro.com</a>>; Kinney, Michael D > > > > > > > <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>> > > > > > > > Cc: lichao <<a href="mailto:lichao@loongson.cn">lichao@loongson.cn</a>>; Kirkendall, Garrett > > > > > > > <<a href="mailto:Garrett.Kirkendall@amd.com">Garrett.Kirkendall@amd.com</a>>; Grimes, Paul > > > > > > > <<a href="mailto:Paul.Grimes@amd.com">Paul.Grimes@amd.com</a>>; He, Jiangang > <<a href="mailto:Jiangang.He@amd.com">Jiangang.He@amd.com</a>>; > > > > > > > Andrew Fish <<a href="mailto:afish@apple.com">afish@apple.com</a>> > > > > > > > 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 <<a href="mailto:Abner.Chang@amd.com">Abner.Chang@amd.com</a>> > > > > > > > > Sent: Sunday, October 2, 2022 8:13 PM > > > > > > > > To: Kinney, Michael D <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>>; > > > > > > > > <a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a>; <a href="mailto:quic_llindhol@quicinc.com"> quic_llindhol@quicinc.com</a>; Ni, Ray > > > > > > > > <<a href="mailto:ray.ni@intel.com">ray.ni@intel.com</a>>; Attar, AbdulLateef (Abdul Lateef) > > > > > > > > <<a href="mailto:AbdulLateef.Attar@amd.com">AbdulLateef.Attar@amd.com</a>>; Sunil V L > > > > > > > > <<a href="mailto:sunilvl@ventanamicro.com">sunilvl@ventanamicro.com</a>> > > > > > > > > Cc: lichao <<a href="mailto:lichao@loongson.cn">lichao@loongson.cn</a>>; Kirkendall, Garrett > > > > > > > > <<a href="mailto:Garrett.Kirkendall@amd.com">Garrett.Kirkendall@amd.com</a>>; Grimes, Paul > > > > > <<a href="mailto:Paul.Grimes@amd.com">Paul.Grimes@amd.com</a>>; > > > > > > > He, > > > > > > > > Jiangang <<a href="mailto:Jiangang.He@amd.com">Jiangang.He@amd.com</a>>; Andrew Fish > > > > > > > > <<a href="mailto:afish@apple.com">afish@apple.com</a>> > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > <a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F"> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F</a> > > > > > ed > > > > > > > k > > > > > > > 2 > > > > > > > > > > > > > > > > > > .groups.io%2Fg%2Fdevel%2Fmessage%2F94567&data=05%7C01%7C > A > > > > > > > bner.Chan > > > > > > > > > > > > > > > > > > > > > > > > > > g%40amd.com%7Cd49cbbe6d3d942bd69a308daa4fea41b%7C3dd8961fe4884 > > > > > > > e608e11a > > > > > > > > > > > > > > > > > > > > > > > > > > 82d994e183d%7C0%7C0%7C638003710850252776%7CUnknown%7CTWFpbGZ > > > > > > > sb3d8eyJWI > > > > > > > > > > > > > > > > > > > > > > > > > > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3 > > > > > > > 000%7 > > > > > > > > > > > > > > > > > > > > > > > C%7C%7C&sdata=eiLOC0G9WZWKqm2ALcAiKr7SPBP5AgDdAxogHlv5pI > > > > > > > M%3D&r > > > > > > > > eserved=0 > > > > > > > > SmmCpuFeatureLib\Ia32 > > > > > > > > SmmCpuFeatureLib\X64 > > > > > > > > SmmCpuFeatureLib\SmmCpuFeatureLib.c > > > > > > > > SmmCpuFeatureLib\SmmCpuFeatureLibCommon.c > > > > > > > > SmmCpuFeatureLib\IntelSmmCPuFeaturesLib > > > > > > > > SmmCpuFeatureLib\AmdlSmmCPuFeaturesLib > > > > > > > > > > > > > > > > > > > > > > > > > > Could we concatenate architectures? > > > > > > > > > > I.e. AARCH64_ARM, IA32_X64, AARCH64_RISCV64... ? > > > > > > > > Looks like below? > > > > > > > > > > > > > > > > CpuDxe\IA32_X64\IA32\abc.nasm > > CpuDxe\IA32_X64\X64\abc.nasm > > > > > > > > CpuDxe\IA32_X64\CpuDxe.c CpuDxe\IA32_X64\AmdCpuDxe.c > > > > > > > > CpuDxe\IA32_X64\IntelCpuDxe.c CpuDxe\RiscV64\CpuDxe.c > > > > > > > > CpuDxe\ARM\CpuDxe.c CpuDxe\ > > > > > > > > CpuDxeCommon.c // If required. > > > > > > > > CpuDxe.inf // Use INF section arch modifier for > X86, > > > > > RISC-V > > > > > > > and ARM. > > > > > > > > CpuDxeAmd.inf // Separate INF for AMD. > > > > > > > > > > > > > > > > Seems ok, but is AARCH64_RISCV64 a real case? Or it means > > > > > > > > we can create a folder "AARCH64_RISCV64" when there are > some > > > > > > > > common > > > > > files > > > > > > > shared by AARCH64 and RISCV64? > > > > > > > > > > > > > > > > For the 32/64 bit support, it can still stay under module > > > > > > > > root and don't need to assign a folder for them unless the > > > > > > > > arch has the different > > > > > > > implementation. > > > > > > > > Regards, > > > > > > > > Abner > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Kinney, Michael D <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>> > > > > > > > > > Sent: Saturday, October 1, 2022 2:52 AM > > > > > > > > > To: <a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a>; <a href="mailto:quic_llindhol@quicinc.com">quic_llindhol@quicinc.com</a>; > > > > > > > > > Chang, Abner <<a href="mailto:Abner.Chang@amd.com">Abner.Chang@amd.com</a>>; Ni, Ray > > > > > > > > > <<a href="mailto:ray.ni@intel.com">ray.ni@intel.com</a>>; Attar, AbdulLateef (Abdul Lateef) > > > > > > > > > <<a href="mailto:AbdulLateef.Attar@amd.com">AbdulLateef.Attar@amd.com</a>>; Sunil V L > > > > > > > > > <<a href="mailto:sunilvl@ventanamicro.com">sunilvl@ventanamicro.com</a>>; Kinney, Michael D > > > > > > > > > <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>> > > > > > > > > > Cc: lichao <<a href="mailto:lichao@loongson.cn">lichao@loongson.cn</a>>; Kirkendall, Garrett > > > > > > > > > <<a href="mailto:Garrett.Kirkendall@amd.com">Garrett.Kirkendall@amd.com</a>>; Grimes, Paul > > > > > > > > > <<a href="mailto:Paul.Grimes@amd.com">Paul.Grimes@amd.com</a>>; He, Jiangang > > <<a href="mailto:Jiangang.He@amd.com">Jiangang.He@amd.com</a>>; > > > > > > > > > Andrew Fish <<a href="mailto:afish@apple.com">afish@apple.com</a>> > > > > > > > > > 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: <a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a> <<a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a>> On > > > > > > > > > > Behalf Of Leif Lindholm > > > > > > > > > > Sent: Friday, September 30, 2022 9:09 AM > > > > > > > > > > To: <a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a>; Kinney, Michael D > > > > > > > > > > <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>>; Chang, Abner > > > > > > > <<a href="mailto:Abner.Chang@amd.com">Abner.Chang@amd.com</a>>; > > > > > > > > > > Ni, Ray <<a href="mailto:ray.ni@intel.com">ray.ni@intel.com</a>>; Attar, AbdulLateef (Abdul > > > > > > > > > > Lateef) <<a href="mailto:AbdulLateef.Attar@amd.com">AbdulLateef.Attar@amd.com</a>>; Sunil V L > > > > > > > > > > <<a href="mailto:sunilvl@ventanamicro.com">sunilvl@ventanamicro.com</a>> > > > > > > > > > > Cc: lichao <<a href="mailto:lichao@loongson.cn">lichao@loongson.cn</a>>; Kirkendall, Garrett > > > > > > > > > > <<a href="mailto:Garrett.Kirkendall@amd.com">Garrett.Kirkendall@amd.com</a>>; Grimes, Paul > > > > > > > <<a href="mailto:Paul.Grimes@amd.com">Paul.Grimes@amd.com</a>>; > > > > > > > > > > He, Jiangang <<a href="mailto:Jiangang.He@amd.com">Jiangang.He@amd.com</a>>; Andrew Fish > > > > > > > <<a href="mailto:afish@apple.com">afish@apple.com</a>> > > > > > > > > > > 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 <<a href="mailto:Abner.Chang@amd.com">Abner.Chang@amd.com</a>> > > > > > > > > > > >> Sent: Friday, September 30, 2022 12:11 AM > > > > > > > > > > >> To: Ni, Ray <<a href="mailto:ray.ni@intel.com">ray.ni@intel.com</a>>; Attar, AbdulLateef > > > > > > > > > > >> (Abdul > > > > > > > > > > >> Lateef) <<a href="mailto:AbdulLateef.Attar@amd.com">AbdulLateef.Attar@amd.com</a>>; Sunil V L > > > > > > > > > > >> <<a href="mailto:sunilvl@ventanamicro.com">sunilvl@ventanamicro.com</a>>; <a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a>; > > > > > > > > > > >> Kinney, Michael D <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>> > > > > > > > > > > >> Cc: lichao <<a href="mailto:lichao@loongson.cn">lichao@loongson.cn</a>>; Kirkendall, Garrett > > > > > > > > > > >> <<a href="mailto:Garrett.Kirkendall@amd.com">Garrett.Kirkendall@amd.com</a>>; Grimes, Paul > > > > > > > > > > >> <<a href="mailto:Paul.Grimes@amd.com">Paul.Grimes@amd.com</a>>; He, Jiangang > > > > > <<a href="mailto:Jiangang.He@amd.com">Jiangang.He@amd.com</a>>; > > > > > > > Leif > > > > > > > > > > >> Lindholm <<a href="mailto:quic_llindhol@quicinc.com">quic_llindhol@quicinc.com</a>>; Andrew Fish > > > > > > > > > > >> <<a href="mailto:afish@apple.com">afish@apple.com</a>> > > > > > > > > > > >> Subject: RE: [edk2-devel] The principles of EDK2 > > > > > > > > > > >> module reconstruction for archs > > > > > > > > > > >> > > > > > > > > > > >> [AMD Official Use Only - General] > > > > > > > > > > >> > > > > > > > > > > >> Thanks Ray, here are my responses. > > > > > > > > > > >> <a href="https://nam11.safelinks.protection.outlook.com/?url=h"> https://nam11.safelinks.protection.outlook.com/?url=h</a> > > > > > > > > > > >> tt > > > > > > > > > > >> ps%3 > > > > > > > > > > >> A%2F > > > > > > > > > > >> %2Fg > > > > > > > > > > >> ithub.com%2Ftianocore-docs%2Fedk2- > > > > > > > CCodingStandardsSpecification > > > > > > > > > > >> %2Fp > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > ull%2F2&data=05%7C01%7CAbner.Chang%40amd.com%7C7c3292c8bd2 > > > > > > > f4 > > > > > > > > > 86f > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > 920908daa314e8e6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6 > > > > > > > > > 3800 > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > 1607445876768%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC > > > > > > > JQ > > > > > > > > > IjoiV > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata > > > > > > > = > > > > > > > > > HAq > > > > > > > > > > >> > > > > > > > > > > > > > > ou4JyY1yxDthuQ1dEKcF7Q3o4W77Oo9rOOvkXNWU%3D&reserved=0 > > > > > > > > > > >> > > > > > > > > > > >> @Kinney, Michael D we may also need your > > > > > > > > > > >> clarification on the > > > > > > > comments. > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >>> -----Original Message----- > > > > > > > > > > >>> From: Ni, Ray <<a href="mailto:ray.ni@intel.com">ray.ni@intel.com</a>> > > > > > > > > > > >>> Sent: Thursday, September 29, 2022 3:42 PM > > > > > > > > > > >>> To: Attar, AbdulLateef (Abdul Lateef) > > > > > > > > > > >>> <<a href="mailto:AbdulLateef.Attar@amd.com">AbdulLateef.Attar@amd.com</a>>; Chang, Abner > > > > > > > > > > >>> <<a href="mailto:Abner.Chang@amd.com">Abner.Chang@amd.com</a>>; Sunil V L > > > > > > > > > > >>> <<a href="mailto:sunilvl@ventanamicro.com">sunilvl@ventanamicro.com</a>>; <a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a> > > > > > > > > > > >>> Cc: Kinney, Michael D <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>>; > > > > > > > > > > >>> lichao <<a href="mailto:lichao@loongson.cn">lichao@loongson.cn</a>>; Kirkendall, Garrett > > > > > > > > > > >>> <<a href="mailto:Garrett.Kirkendall@amd.com">Garrett.Kirkendall@amd.com</a>>; Grimes, Paul > > > > > > > > > > >>> <<a href="mailto:Paul.Grimes@amd.com">Paul.Grimes@amd.com</a>>; He, Jiangang > > > > > <<a href="mailto:Jiangang.He@amd.com">Jiangang.He@amd.com</a>>; > > > > > > > > > > >>> Leif Lindholm <<a href="mailto:quic_llindhol@quicinc.com">quic_llindhol@quicinc.com</a>>; Andrew > > > > > > > > > > >>> Fish <<a href="mailto:afish@apple.com">afish@apple.com</a>> > > > > > > > > > > >>> 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 > > > > > > > > > > >>> <a href="https://nam11.safelinks.protection.outlook.com/?url="> https://nam11.safelinks.protection.outlook.com/?url=</a> > > > > > > > > > > >>> ht > > > > > > > > > > >>> tps% > > > > > > > > > > >>> 3A%2 > > > > > > > > > > >>> F%2F > > > > > > > > > > >>> gith > > > > > > > > > > >>> ub.com%2Ftianocore-docs%2Fedk2- > > > > > > > > > > >>> > CCodingStandardsSpecification%2Fpull%2F2%23pullreque > > > > > > > > > > >>> st > > > > > > > > > > >>> revi > > > > > > > > > > >>> ew- > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > 1124763311&data=05%7C01%7CAbner.Chang%40amd.com%7Cd825e24 > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > 8625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82d994e183d%7C0 > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > %7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > C > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000% > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > 7C%7C%7C&sdata=RXxgpbEr6ivbqP1R6%2B3Rxl%2ByJAnaUJuaYYKdfCH > > > > > > > > > > >>> 8jo8%3D&reserved=0 > > > > > > > > > > >>> > > > > > > > > > > >>> We can discuss more in tomorrow's meeting. > > > > > > > > > > >>> > > > > > > > > > > >>> > > > > > > > > > > >>>> -----Original Message----- > > > > > > > > > > >>>> From: Attar, AbdulLateef (Abdul Lateef) > > > > > > > > > > >>>> <<a href="mailto:AbdulLateef.Attar@amd.com">AbdulLateef.Attar@amd.com</a>> > > > > > > > > > > >>>> Sent: Thursday, September 29, 2022 3:11 PM > > > > > > > > > > >>>> To: Chang, Abner <<a href="mailto:Abner.Chang@amd.com">Abner.Chang@amd.com</a>>; Sunil V L > > > > > > > > > > >>>> <<a href="mailto:sunilvl@ventanamicro.com">sunilvl@ventanamicro.com</a>>; <a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a>; > > > > > > > > > > >>>> Ni, Ray <<a href="mailto:ray.ni@intel.com">ray.ni@intel.com</a>> > > > > > > > > > > >>>> Cc: Kinney, Michael D <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>>; > > > > > > > > > > >>>> lichao <<a href="mailto:lichao@loongson.cn">lichao@loongson.cn</a>>; Kirkendall, Garrett > > > > > > > > > > >>>> <<a href="mailto:Garrett.Kirkendall@amd.com">Garrett.Kirkendall@amd.com</a>>; Grimes, Paul > > > > > > > > > > >>>> <<a href="mailto:Paul.Grimes@amd.com">Paul.Grimes@amd.com</a>>; > > > > > > > > > > >>> He, > > > > > > > > > > >>>> Jiangang <<a href="mailto:Jiangang.He@amd.com">Jiangang.He@amd.com</a>>; Leif Lindholm > > > > > > > > > > >>>> <<a href="mailto:quic_llindhol@quicinc.com">quic_llindhol@quicinc.com</a>>; Andrew Fish > > > > > > > > > > >>>> <<a href="mailto:afish@apple.com">afish@apple.com</a>> > > > > > > > > > > >>>> Subject: RE: [edk2-devel] The principles of EDK2 > > > > > > > > > > >>>> module reconstruction for archs > > > > > > > > > > >>>> > > > > > > > > > > >>>> Hi Abner, > > > > > > > > > > >>>> Looks good to me. > > > > > > > > > > >>>> Reviewed-by: Abdul Lateef Attar <<a href="mailto:abdattar@amd.com">abdattar@amd.com</a>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> Thanks > > > > > > > > > > >>>> AbduL > > > > > > > > > > >>>> > > > > > > > > > > >>>> -----Original Message----- > > > > > > > > > > >>>> From: Chang, Abner <<a href="mailto:Abner.Chang@amd.com">Abner.Chang@amd.com</a>> > > > > > > > > > > >>>> Sent: 28 September 2022 20:31 > > > > > > > > > > >>>> To: Sunil V L <<a href="mailto:sunilvl@ventanamicro.com">sunilvl@ventanamicro.com</a>>; > > > > > > > > > > >>>> <a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a>; <a href="mailto:ray.ni@intel.com">ray.ni@intel.com</a> > > > > > > > > > > >>>> Cc: Kinney, Michael D <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>>; > > > > > > > > > > >>>> lichao <<a href="mailto:lichao@loongson.cn">lichao@loongson.cn</a>>; Kirkendall, Garrett > > > > > > > > > > >>>> <<a href="mailto:Garrett.Kirkendall@amd.com">Garrett.Kirkendall@amd.com</a>>; Grimes, Paul > > > > > > > > > > >>>> <<a href="mailto:Paul.Grimes@amd.com">Paul.Grimes@amd.com</a>>; > > > > > > > > > > >>> He, > > > > > > > > > > >>>> Jiangang <<a href="mailto:Jiangang.He@amd.com">Jiangang.He@amd.com</a>>; Attar, AbdulLateef > > > > > > > > > > >>>> (Abdul > > > > > > > > > > >>>> Lateef) <<a href="mailto:AbdulLateef.Attar@amd.com">AbdulLateef.Attar@amd.com</a>>; Leif Lindholm > > > > > > > > > > >>>> <<a href="mailto:quic_llindhol@quicinc.com">quic_llindhol@quicinc.com</a>>; Andrew Fish > > > > > > > > > > >>>> <<a href="mailto:afish@apple.com">afish@apple.com</a>> > > > > > > > > > > >>>> 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: > > > > > > > > > > >>>> > > > > > > > > > > >>> <a href="https://nam11.safelinks.protection.outlook.com/?url="> https://nam11.safelinks.protection.outlook.com/?url=</a> > > > > > > > > > > >>> ht > > > > > > > > > > >>> tps% > > > > > > > > > > >>> 3A%2 > > > > > > > > > > >>> F%2F > > > > > > > > > > >>> gith > > > > > > > > > > >>>> ub.com%2Ftianocore-docs%2Fedk2- > > > > > > > > > > >>> &data=05%7C01%7CAbner.Chang%40amd.c > > > > > > > > > > >>>> > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > om%7Cd825e248625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82 > > > > > > > > > > >>> d994e18 > > > > > > > > > > >>>> > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > 3d%7C0%7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJ > > > > > > > > > > >>> WIjoiMC4wLj > > > > > > > > > > >>>> > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C% > > > > > > > > > > >>> 7C%7C&a > > > > > > > > > > >>>> > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > mp;sdata=X4z9puj81nIGTqtMxC9igDZyBPOT6OTWSU%2BjoIowo%2BE%3D&a > > > > > > > > > > >>> mp;reserv > > > > > > > > > > >>>> ed=0 > > > > > > > > > > >>>> CCodingStandardsSpecification/pull/2 > > > > > > > > > > >>>> > > > > > > > > > > >>>> The naming rule is mainly for the new module or new > file > > IMO. > > > > > > > > > > >>>> Some existing module may not meet the guidelines > > > > > > > > > > >>>> mentioned in this > > > > > > > > > spec. > > > > > > > > > > >>>> Thus we need the principles of EDK2 module > > > > > > > > > > >>>> reconstruction on the existing module to support > > > > > > > > > > >>>> other processor archs and not impacting the > > > > > > > > > > >>> existing platforms (e.g. > > > > > > > > > > >>>> rename the INF file or directory to meet the > guidelines). > > > > > > > > > > >>>> > > > > > > > > > > >>>> Sunil, seems RISC-V CpuDxe meet the guideline. > > > > > > > > > > >>>> Please check > > > > > it. > > > > > > > > > > >>>> Just feel that having CpuDxe.c to Riscv64 folder > > > > > > > > > > >>>> is not quite a best solution. I think at least we > > > > > > > > > > >>>> can abstract the protocol structure and protocol > > > > > > > > > > >>>> installation under CpuDxe\ and have the arch > > > > > > > > > > >>>> implementation under arch folder. We can discuss > > > > > > > > > > >>>> this later after we confirming the > > > > > > > > > > >>> guideline and principles. > > > > > > > > > > >>>> > > > > > > > > > > >>>> Thanks > > > > > > > > > > >>>> Abner > > > > > > > > > > >>>> > > > > > > > > > > >>>>> -----Original Message----- > > > > > > > > > > >>>>> From: Sunil V L <<a href="mailto:sunilvl@ventanamicro.com">sunilvl@ventanamicro.com</a>> > > > > > > > > > > >>>>> Sent: Wednesday, September 28, 2022 3:34 PM > > > > > > > > > > >>>>> To: <a href="mailto:devel@edk2.groups.io">devel@edk2.groups.io</a>; <a href="mailto:ray.ni@intel.com">ray.ni@intel.com</a> > > > > > > > > > > >>>>> Cc: Chang, Abner <<a href="mailto:Abner.Chang@amd.com">Abner.Chang@amd.com</a>>; Kinney, > > > > > Michael > > > > > > > > > > >>>>> D <<a href="mailto:michael.d.kinney@intel.com">michael.d.kinney@intel.com</a>>; lichao > > > > > > > > > > >>>>> <<a href="mailto:lichao@loongson.cn">lichao@loongson.cn</a>>; Kirkendall, Garrett > > > > > > > > > > >>>>> <<a href="mailto:Garrett.Kirkendall@amd.com">Garrett.Kirkendall@amd.com</a>>; Grimes, Paul > > > > > > > > > > >>>>> <<a href="mailto:Paul.Grimes@amd.com">Paul.Grimes@amd.com</a>>; He, Jiangang > > > > > > > > > > >>>>> <<a href="mailto:Jiangang.He@amd.com">Jiangang.He@amd.com</a>>; Attar, AbdulLateef (Abdul > > > > > > > > > > >>>>> Lateef) <<a href="mailto:AbdulLateef.Attar@amd.com">AbdulLateef.Attar@amd.com</a>>; Leif > Lindholm > > > > > > > > > > >>>>> <<a href="mailto:quic_llindhol@quicinc.com">quic_llindhol@quicinc.com</a>>; Andrew Fish > > > > > > > > > > >>>>> <<a href="mailto:afish@apple.com">afish@apple.com</a>> > > > > > > > > > > >>>>> Subject: Re: [edk2-devel] The principles of EDK2 > > > > > > > > > > >>>>> module reconstruction for archs > > > > > > > > > > >>>>> > > > > > > > > > > >>>>> Caution: This message originated from an External > > Source. > > > > > > > > > > >>>>> Use proper caution when opening attachments, > > > > > > > > > > >>>>> clicking links, or > > > > > > > responding. > > > > > > > > > > >>>>> > > > > > > > > > > >>>>> > > > > > > > > > > >>>>> On Wed, Sep 28, 2022 at 03:33:45AM +0000, Ni, Ray > > wrote: > > > > > > > > > > >>>>> Hi Ray, > > > > > > > > > > >>>>>> > > > > > > > > > > >>>>>> 1. When a new arch's implementation is > > > > > > > > > > >>>>>> introduced to the existing > > > > > > > > > > >>>>> module which was developed for the specific arch: > > > > > > > > > > >>>>>> > > > > > > > > > > >>>>>> 1. The folder reconstruction: > > > > > > > > > > >>>>>> > > > > > > > > > > >>>>>> * Create arch folder for the existing arch > > implementation > > > > > > > > > > >>>>>> [Ray] Do you move existing arch implementation to > > > > > > > > > > >>>>>> that arch > > > > > > > folder? > > > > > > > > > > >>>>>> It will > > > > > > > > > > >>>>> break existing platforms a lot. > > > > > > > > > > >>>>>> > > > > > > > > > > >>>>>> * Create the arch folder for the new introduced > > arch > > > > > > > > > > >>>>>> [Ray] I agree. But if we don't create arch folder > > > > > > > > > > >>>>>> for existing arch > > > > > > > > > > >>>>> implementation, the pkg layout will be a mess. > > > > > > > > > > >>>>>> > > > > > > > > > > >>>>>> [Ray] Hard for me to understand all the principles > here. > > > > > > > > > > >>>>>> Maybe we review > > > > > > > > > > >>>>> existing code including to-be-upstreamed code and > > > > > > > > > > >>>>> decide how > > > > > > > to go. > > > > > > > > > > >>>>>> > > > > > > > > > > >>>>> > > > > > > > > > > >>>>> Could you please take a look below changes which > > > > > > > > > > >>>>> is trying to add RISC-V support for CpuDxe? > > > > > > > > > > >>>>> > > > > > > > > > > >>>> > > > > > > > > > > >>> <a href="https://nam11.safelinks.protection.outlook.com/?url="> https://nam11.safelinks.protection.outlook.com/?url=</a> > > > > > > > > > > >>> ht > > > > > > > > > > >>> tps% > > > > > > > > > > >>> 3A%2 > > > > > > > > > > >>> F%2F > > > > > > > > > > >>> gith > > > > > > > > > > >>>>> ub.com%2Ftianocore%2Fedk2- > > > > > > > > > > >>>>> > > > > > > > > > > >>>> > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > staging%2Fcommit%2Fbba1a11be47dd091734e185afbed73ea75708749& > > > > > > > > > > >>>>> > > > > > > > > > > >>>> > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > data=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08d > > > > > > > > > > >>>>> > > > > > > > > > > >>>> > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > aa123e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947 > > > > > > > > > > >>>>> > > > > > > > > > > >>>> > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > 2732494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj > > > > > > > > > > >>>>> > > > > > > > > > > >>>> > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd > > > > > > > > > > >>>>> > > > > > > > > > > >>>> > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > ata=Vq6pJLnn8yJrJhFZn7LfLbZzrtpG4n1VLWgAil6J38U%3D&reserved=0 > > > > > > > > > > >>>>> > > > > > > > > > > >>>> > > > > > > > > > > >>> <a href="https://nam11.safelinks.protection.outlook.com/?url="> https://nam11.safelinks.protection.outlook.com/?url=</a> > > > > > > > > > > >>> ht > > > > > > > > > > >>> tps% > > > > > > > > > > >>> 3A%2 > > > > > > > > > > >>> F%2F > > > > > > > > > > >>> gith > > > > > > > > > > >>>>> ub.com%2Ftianocore%2Fedk2- > > > > > > > > > > >>>>> > > > > > > > > > > >>>> > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > staging%2Fcommit%2F7fccf92a97a6d0618a20f10622220e78b3687906&da > > > > > > > > > > >>>>> > > > > > > > > > > >>>> > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > ta=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08daa1 > > > > > > > > > > >>>>> > > > > > > > > > > >>>> > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > 23e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947273 > > > > > > > > > > >>>>> > > > > > > > > > > >>>> > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > 2494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV > > > > > > > > > > >>>>> > > > > > > > > > > >>>> > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata > > > > > > > > > > >>>>> > > > > > > > > > > >>>> > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > =xFmvUv58vh4AUAM17Qy9G5jZWFZlK2Ozt3njpG1e8%2BY%3D&reserv > > > > > > > > > > >>>>> ed=0 > > > > > > > > > > >>>>> > > > > > > > > > > >>>>> What do you suggest with above example? > > > > > > > > > > >>>>> > > > > > > > > > > >>>>> 1) Common INF for all architectures - but modify > > > > > > > > > > >>>>> INF alone, no > > > > > > > > > > >>>>> X86 folder creation. > > > > > > > > > > >>>>> > > > > > > > > > > >>>>> This is what I have done in the commit above. May > > > > > > > > > > >>>>> be of least impact to existing code since it is only INF > > change. > > > > > > > > > > >>>>> But like you mentioned this is bit weird that X86 > > > > > > > > > > >>>>> files will remain in root folder directly along > > > > > > > > > > >>>>> with some common > > > > > files. > > > > > > > > > > >>>>> > > > > > > > > > > >>>>> 2) Common INF (CpuDxe.inf) + create arch folders > > > > > > > > > > >>>>> X86, X64, IA32, > > > > > > > > > > >>>>> RiscV64 etc > > > > > > > > > > >>>>> > > > > > > > > > > >>>>> IMO, this is probably the best approach. What > > > > > > > > > > >>>>> would be the challenges with this? > > > > > > > > > > >>>>> > > > > > > > > > > >>>>> 3) Separate INF for arch like CpuDxe.inf for x86, > > > > > > > > > > >>>>> CpuDxeRiscV64.inf for > > > > > > > > > > >>>> RISC-V. > > > > > > > > > > >>>>> > > > > > > > > > > >>>>> This again probably is not a good idea. > > > > > > > > > > >>>>> > > > > > > > > > > >>>>> 4) If the module/library is specific to one arch (ex: > > > > > > > > > > >>>>> SMM(X86), SBI(RISC-V)), then create separate INF. > > > > > > > > > > >>>>> > > > > > > > > > > >>>>> Thanks! > > > > > > > > > > >>>>> Sunil > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ><o:p></o:p> </div> </div> </div> </div> </div> </body> </html> <div width="1" style="color:white;clear:both">_._,_._,_</div> <hr> Groups.io Links: You receive all messages sent to this group. <a target="_blank" href="https://edk2.groups.io/g/devel/message/95010">View/Reply Online (#95010)</a> | | <a target="_blank" href="https://groups.io/mt/93872791/1813853">Mute This Topic</a> | <a href="https://edk2.groups.io/g/devel/post">New Topic</a> <a href="https://edk2.groups.io/g/devel/editsub/1813853">Your Subscription</a> | <a href="mailto:devel+owner@edk2.groups.io">Contact Group Owner</a> | <a href="https://edk2.groups.io/g/devel/unsub">Unsubscribe</a> [edk2-devel-archive@redhat.com] <div width="1" style="color:white;clear:both">_._,_._,_</div>