From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) by mx.groups.io with SMTP id smtpd.web12.783.1664554115488528950 for ; Fri, 30 Sep 2022 09:08:35 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=OJ1D1q/Q; spf=permerror, err=parse error for token &{10 18 %{ir}.%{v}.%{d}.spf.has.pphosted.com}: invalid domain name (domain: quicinc.com, ip: 199.106.114.38, mailfrom: quic_llindhol@quicinc.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1664554115; x=1696090115; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=HY/qtb+cgX/r71lPiHIRBoPVMsBmCHRu+m8ku6hNVdE=; b=OJ1D1q/QLvnmYUaFdCqIZVmV/Jfi+15dEjj6UP4BUC2Uks/xilgvdfGX iGcBVHzeNkjM2jUrumvWSvlOwT2QBuBE1ZYXbf9vjflUpMAXa31r+GMa8 UYwkBcAHu5rwtAJY9GKNdKtpc4WOtLvHRmPMMgbiJ0D8brvJOT/GlN9bT E=; Received: from unknown (HELO ironmsg04-sd.qualcomm.com) ([10.53.140.144]) by alexa-out-sd-01.qualcomm.com with ESMTP; 30 Sep 2022 09:08:35 -0700 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.45.79.139]) by ironmsg04-sd.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2022 09:08:35 -0700 Received: from [10.110.0.61] (10.80.80.8) by nasanex01c.na.qualcomm.com (10.45.79.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.29; Fri, 30 Sep 2022 09:08:34 -0700 Message-ID: <0c1ee7b8-9ecf-3f46-ac36-9d1464831263@quicinc.com> Date: Fri, 30 Sep 2022 09:08:33 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [edk2-devel] The principles of EDK2 module reconstruction for archs To: , , "Chang, Abner" , "Ni, Ray" , "Attar, AbdulLateef (Abdul Lateef)" , Sunil V L CC: lichao , "Kirkendall, Garrett" , "Grimes, Paul" , "He, Jiangang" , Andrew Fish References: From: "Leif Lindholm" In-Reply-To: Return-Path: quic_llindhol@quicinc.com X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nasanex01c.na.qualcomm.com (10.45.79.139) Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit 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- >>> 1124763311&data=05%7C01%7CAbner.Chang%40amd.com%7Cd825e24 >>> 8625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82d994e183d%7C0 >>> %7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC >>> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000% >>> 7C%7C%7C&sdata=RXxgpbEr6ivbqP1R6%2B3Rxl%2ByJAnaUJuaYYKdfCH >>> 8jo8%3D&reserved=0 >>> >>> We can discuss more in tomorrow's meeting. >>> >>> >>>> -----Original Message----- >>>> From: Attar, AbdulLateef (Abdul Lateef) >>>> 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.ni@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&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 >>>>> Sent: Wednesday, September 28, 2022 3:34 PM >>>>> To: devel@edk2.groups.io; ray.ni@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 +0000, Ni, Ray wrote: >>>>> Hi Ray, >>>>>> >>>>>> 1. When a new arch's implementation is introduced to the >>>>>> existing >>>>> module which was developed for the specific arch: >>>>>> >>>>>> 1. The folder reconstruction: >>>>>> >>>>>> * Create arch folder for the existing arch implementation >>>>>> [Ray] Do you move existing arch implementation to that arch folder? >>>>>> It will >>>>> break existing platforms a lot. >>>>>> >>>>>> * Create the arch folder for the new introduced arch >>>>>> [Ray] I agree. But if we don't create arch folder for existing >>>>>> arch >>>>> implementation, the pkg layout will be a mess. >>>>>> >>>>>> [Ray] Hard for me to understand all the principles here. Maybe we >>>>>> review >>>>> existing code including to-be-upstreamed code and decide how to go. >>>>>> >>>>> >>>>> Could you please take a look below changes which is trying to add >>>>> RISC-V support for CpuDxe? >>>>> >>>> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith >>>>> ub.com%2Ftianocore%2Fedk2- >>>>> >>>> >>> staging%2Fcommit%2Fbba1a11be47dd091734e185afbed73ea75708749& >>>>> >>>> >>> data=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08d >>>>> >>>> >>> aa123e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947 >>>>> >>>> >>> 2732494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj >>>>> >>>> >>> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd >>>>> >>>> >>> ata=Vq6pJLnn8yJrJhFZn7LfLbZzrtpG4n1VLWgAil6J38U%3D&reserved=0 >>>>> >>>> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith >>>>> 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 > > > > >