From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (NAM10-DM6-obe.outbound.protection.outlook.com [40.107.93.75]) by mx.groups.io with SMTP id smtpd.web11.10957.1664892331285939329 for ; Tue, 04 Oct 2022 07:05:31 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@amd.com header.s=selector1 header.b=blKVk11L; spf=permerror, err=parse error for token &{10 18 %{i}._ip.%{h}._ehlo.%{d}._spf.vali.email}: invalid domain name (domain: amd.com, ip: 40.107.93.75, mailfrom: abner.chang@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VbNTNubTo72YlVdvFyCrHgHigipts5Q0HHhAukQywVmTtsruKGC90JdMp2O3uAr6OyU6zInyeg7ZKzUWyv7fdL2ABFBoAaFbUY+wR9UGD/+jXsL2sBS+FZtWEYxnqO3J92QYgpcC32+MM6CcV+S8ndgmrwjBDAU5UETHhcJ1WZDPUS4uoHWAZ9mngOO/ALgaI+SVB/ONiTrCktWkGPMdgYUz/9URtzoILtcTt3zLd/F0IK6tqGUaIe7e0wfl6JG4xzOp1WQJnUgj1p9oGPqi8onoqv5oyCt+uMLUaevly0uSdJEGmjPJ46LXnN3RqRUgFf7uRQ5LNFzOiUGGbRpz2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=l3jE6nsFLs8zYCdYQfRbK/ml/3rnaaZ90zvRlDTqaFg=; b=ErEHL7yTHHZJi93Tph4kPkcsi4bLfFHerj042qWlhO//WAhj0AweH917jX2cClqGJGrhB21RsGx87MXA7TFUU2y3A5+RaRAkXfg5ENDJyDm2wGe81val65Cur0pCJb3p6YQj+T0AC4XwiZ4/+RocPVYiEAgMIoGltmmHdGaUzABmstvVrMiCZxtgz/Eel8hAyDwsGoEL2gWOx7ZQP9PBxphFNyHOFBj44LWjh9iEfYf5gLV1J9CIfHium3sEwxlfX61GqAp2FR+F0KdaFH67PJj5yZglCkg6FoQlW4cLRt8vTcfcVM4znd+29oont1MMqkBnRNvBE6bGs14PxEI2bw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l3jE6nsFLs8zYCdYQfRbK/ml/3rnaaZ90zvRlDTqaFg=; b=blKVk11L2pE3SFU2G/vVeN5SBCeDusYvZ8AfTYbGcFeaumm/fADSbXiv2/DcdJn8NWp8RsVUI3NGIQYpp2swupxtkwxIV8R65g7sveOdxEs6o365UL8n39H8xaZZwq23EONkEi8r6Su+gydKEdRqXKaWIP9wYyPF+5blFtP5K34= Received: from MN2PR12MB3966.namprd12.prod.outlook.com (2603:10b6:208:165::18) by SN7PR12MB7322.namprd12.prod.outlook.com (2603:10b6:806:299::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.20; Tue, 4 Oct 2022 14:05:28 +0000 Received: from MN2PR12MB3966.namprd12.prod.outlook.com ([fe80::dd29:6efb:1027:cfb2]) by MN2PR12MB3966.namprd12.prod.outlook.com ([fe80::dd29:6efb:1027:cfb2%5]) with mapi id 15.20.5676.031; Tue, 4 Oct 2022 14:05:28 +0000 From: "Chang, Abner" To: "Kinney, Michael D" , "devel@edk2.groups.io" , "quic_llindhol@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 Thread-Topic: [edk2-devel] The principles of EDK2 module reconstruction for archs Thread-Index: AdjPX4ZZG0rDXS4WTdOIWvoiYOLYcgC9rttQAC2dmIAADxJbkAAiVmtwAABqVrAAMdRUkAARY7IwAAF/rYAABYT70AB0Z6+AAAYqDgAAADksgAAYA9igACxnOYA= Date: Tue, 4 Oct 2022 14:05:27 +0000 Message-ID: References: <0c1ee7b8-9ecf-3f46-ac36-9d1464831263@quicinc.com> In-Reply-To: Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_Enabled=true; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_SetDate=2022-10-04T14:05:25Z; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_Method=Standard; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_Name=General; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_ActionId=9d913f7d-89f2-4e89-836a-3653d5d17ee2; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_ContentBits=1 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MN2PR12MB3966:EE_|SN7PR12MB7322:EE_ x-ms-office365-filtering-correlation-id: e5794993-f2c4-4848-2d0f-08daa6117d99 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: diqNOMLhyfBeNYxaWMePquV0w62Sw1qu19q80Ll3uZVXbu6vBY07qtg0NfvxxTi1jST3y8NI8TiCXdKsozjxEFmCUwmuJY9/p44tRnvCWlWhqUEguq6/DK2e5sGSlOKe2ziuGVWk0HW8F9gij/L5TJOLF8vhHjNoyG3rZ+gEC/fuUg+xZDCwJsX05JupQrkddvRoYtMT/yvqeoOrodWlFl6+vgf36oWFNAnfM276qsj3rWQh7btrF7MtskbBw2bIeIN/LDkCsOqT2MXuG/naNfI7kcfa0cZyq99EC4cCczuHehF6L38hB6HhaoPPLTQHLvtTEfx85eBmE7QA15KgETRVISfS6G42oognNCAE5KWzXJkJFTV4wlkqz1oIO6vQKwHpllg39fJybfS9RHq5eyC007uEs1UFT+b1+v3hyW4gEL0RLCxbF/o6JgmJ3sWu6linVH/RSePWcvgABqWZJzcs5Qi6qvbltMk9QLMfWaEr9Eef2KzQi5SLEjEgoybUQAEBnwJQZeS2L55xhysn+eZ/5CL71KPsGcD2gI98hXUiNV2xti5xRhmnbx2I+PX1FL3HruYIolr8Yk+IX5gHZcYoI1lhTvx+h5JTm3o8mwiylBnPyDEPVJQAiCfTVdELEJYO6iFDvzfDKWpsOm/AQZp1BnDHtCTPS+C+pg7PbjgkEedCTbR+C/OQpFpJ2QET+ZSuhZSAHhSiP9aVLfDDGo6UwSc5baRoVrNfBTOycuRMxhBhLsWKr3vLq7KXjfmxoRLYYViQXYu0kBW0oVJhnguh1gIUttinPIbh3whya96YnQmH2D7+YA2bT2jxnWodPtBJBTnvb3/j9KScFVnCww== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR12MB3966.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(396003)(376002)(366004)(39860400002)(346002)(136003)(451199015)(45080400002)(2906002)(19627235002)(38100700002)(4326008)(122000001)(66476007)(76116006)(316002)(54906003)(33656002)(86362001)(38070700005)(110136005)(66556008)(66946007)(66446008)(8676002)(64756008)(8936002)(52536014)(30864003)(41300700001)(186003)(53546011)(26005)(6506007)(7696005)(9686003)(5660300002)(55016003)(71200400001)(966005)(478600001)(83380400001)(66899015)(559001)(579004);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Z0fyJ70V/U7JaPNfCuiG3jMLhV3bqhwaFwakdSjhRqHRutU7jNGs2VFMkszR?= =?us-ascii?Q?TbBpQ9Yv/hExa+JSKO08HZ+B6TJLTR2NjaQCjtHFehLbtSCnVPOacog+MU89?= =?us-ascii?Q?ymcyZxhNy+zswuus7DAEmThSMjhZIh89EIbM5KhXuQpOgO7HDhNp5AA3ukST?= =?us-ascii?Q?m+fjlG28wIJMziB5BDQ/SzNnTSSIuHLmxJ+IAD8BoV4SYO9wgf93q9lYe6ra?= =?us-ascii?Q?mNBYnMChbWl05sF/H2QcV2EycEOc9pJeJ42+mgWO8rFvwiiLiJlAvnv8JgIu?= =?us-ascii?Q?G1UkZ3L+8dKgQ4kPSj1cn1eLdQYWJ/Gc76nC5qYJMS1UaM76dGvD3yFwWwEm?= =?us-ascii?Q?y6CLAiEdA3v76yp5VlVDvXpkr2fDtTbqPY5Vsz34c7eBydRq7ErFdeHi4kzl?= =?us-ascii?Q?G6xDQqwB3nYHfPwYx8opvy+Zc0fHvTAUghsnccCdnh4g4NgxQn7W4B+1Apl0?= =?us-ascii?Q?icDYapfmhzk77hHIuR4vyBxmg4WiSfyzjL8HHe9QPBQK/ZYVyYGfSRF1HNtu?= =?us-ascii?Q?m9RwhfglMeFpE2BccmHLTyHStYkJUFZed+PBaGV3MiV9/e6cmr5SXqcRhkFn?= =?us-ascii?Q?dtoSh1SavGO+j66ViLsE72B13be59ofsJOyViyu6MleR6S8csufq8ozLjxXO?= =?us-ascii?Q?TnP2FrFcFyK5p+ijnvKwPm8iHAHURUoBRClnpQTJSxK67IuFPf44aVYIim9I?= =?us-ascii?Q?VBV0n66OC6eGv6XfQsgUgU+gC7qDfSxpj1+w7jKsvJbzv9+fBFvw/Tlni+s9?= =?us-ascii?Q?v+TSdMQNKY7Fj6mADMeuFP2fXnhLj7FHAZMtxJHJeuU3J/2pZGsA+zjlxBrw?= =?us-ascii?Q?mAgCl27rrUxEWLnOMI1hIZcOskx8H1ye+ZOMqgNZrLDaCqWURrJxiyMySGgt?= =?us-ascii?Q?k8dIeEsWkxPPYXwj9Xn9nN1F6b3ZNndWZ/pt/1o2hzStRASow+n6EO8Qp4wu?= =?us-ascii?Q?FI65EZkCl3mOyM4KWyabcuDqza/+zgUFiQDWcpw88+0zwkJhOH6JAdsQs4zZ?= =?us-ascii?Q?5KAUDQspmZ9U1CiiSJ7abEB7E0kzZ449pXpdJ1CMQ6AbKvQkfT+QPVOECPcA?= =?us-ascii?Q?qkwV0PrYatawQnObMTrtKRszMtC/s9l75FAnknv84i9habEFo1VXblduPjsU?= =?us-ascii?Q?mDL7Occu7S7ITH7m51xIpddFo6dEvPaH8TXj2HEvrrP+g7mJLNhWf+IEnZSq?= =?us-ascii?Q?ieH7u53BqoDbHDmiJviRS2TfEAT6/wzAjcbqDYLvKqHN3lJuvzh5w2nzbX8u?= =?us-ascii?Q?KfnJm8wkVpkDER5HihZbTuuMxaS+aZfm0RdRuGARAUeky4AlifiGTfkKRM3d?= =?us-ascii?Q?iG4FEqgN7IUIcEl/y1LFmgntXs7L1mvvXhpH6fCkLsBxn20LTDjaNzp+SZAn?= =?us-ascii?Q?eWUAwdipwooODQ3l1YsE+vKCG0vl9oGbjPatuC8Dc5/oUdUllanN68wGGaes?= =?us-ascii?Q?q5EUm8YSbxmHP4YTL3Yl+I/xfhOd0zOus61QP3izQEgvsvWG+dKXLArNPDBZ?= =?us-ascii?Q?I4ozkS46KZEp9g+Jc1YhOvy9TYOuFbWhcFqpp+D5va5L0TvF7IkvQ0umo4sk?= =?us-ascii?Q?FJ/pps8zxWzyAfkG9jW335o6LXsqcBOiti2xnjNu?= MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR12MB3966.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e5794993-f2c4-4848-2d0f-08daa6117d99 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2022 14:05:27.7566 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: su76O97C3IR/3WV4utWynlMWZIhGqfwTKhjxhDIQrwFPk7b0LxG48SW+6+AGGIvqOJpmxvQJG0WIaO7+flwllw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7322 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [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_llindhol@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 fo= r > archs >=20 > Caution: This message originated from an External Source. Use proper > caution when opening attachments, clicking links, or responding. >=20 >=20 > Hi Abner, >=20 > responses below. >=20 > Mike >=20 > > -----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_llindhol@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 cre= ated > when necessary. >=20 > Agreed Ok, I will update Directory and file names section. >=20 > > > > Do you agree with the arch concatenate solution for arch folder? That > means IA32_X64 instead of X86 (I am fine with this)? >=20 > Yes >=20 > > 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 fol= der > naming structure, however we let maintainer to make the decision? >=20 > 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 i= s > 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 >=20 > > > > Abner > > > > > > > -----Original Message----- > > > From: Kinney, Michael D > > > Sent: Monday, October 3, 2022 1:18 PM > > > To: Chang, Abner ; devel@edk2.groups.io; > > > quic_llindhol@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_llindhol@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=3Dhttps%3A%2F%2Fed > > > k > > > 2 > > > > > .groups.io%2Fg%2Fdevel%2Fmessage%2F94567&data=3D05%7C01%7CA > > > bner.Chan > > > > > > > > g%40amd.com%7Cd49cbbe6d3d942bd69a308daa4fea41b%7C3dd8961fe4884 > > > e608e11a > > > > > > > > 82d994e183d%7C0%7C0%7C638003710850252776%7CUnknown%7CTWFpbGZ > > > sb3d8eyJWI > > > > > > > > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3 > > > 000%7 > > > > > > > > C%7C%7C&sdata=3DeiLOC0G9WZWKqm2ALcAiKr7SPBP5AgDdAxogHlv5pI > > > M%3D&r > > > > eserved=3D0 > > > > 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 mo= difier 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_llindhol@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 my responses. > > > > > > >> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%= 3 > > > > > > >> A%2F > > > > > > >> %2Fg > > > > > > >> ithub.com%2Ftianocore-docs%2Fedk2- > > > CCodingStandardsSpecification > > > > > > >> %2Fp > > > > > > >> > > > > > > > > > ull%2F2&data=3D05%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 > > > =3D > > > > > HAq > > > > > > >> > > > > ou4JyY1yxDthuQ1dEKcF7Q3o4W77Oo9rOOvkXNWU%3D&reserved=3D0 > > > > > > >> > > > > > > >> @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=3Dhttps= % > > > > > > >>> 3A%2 > > > > > > >>> F%2F > > > > > > >>> gith > > > > > > >>> ub.com%2Ftianocore-docs%2Fedk2- > > > > > > >>> CCodingStandardsSpecification%2Fpull%2F2%23pullrequestrevi > > > > > > >>> ew- > > > > > > >>> > > > > > > > > > 1124763311&data=3D05%7C01%7CAbner.Chang%40amd.com%7Cd825e24 > > > > > > >>> > > > > > > > > > 8625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82d994e183d%7C0 > > > > > > >>> > > > > > > > > > %7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > > > > > > >>> > > > > > > > > > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000% > > > > > > >>> > > > > > > > > > 7C%7C%7C&sdata=3DRXxgpbEr6ivbqP1R6%2B3Rxl%2ByJAnaUJuaYYKdfCH > > > > > > >>> 8jo8%3D&reserved=3D0 > > > > > > >>> > > > > > > >>> 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=3Dhttps= % > > > > > > >>> 3A%2 > > > > > > >>> F%2F > > > > > > >>> gith > > > > > > >>>> ub.com%2Ftianocore-docs%2Fedk2- > > > > > > >>> &data=3D05%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=3DX4z9puj81nIGTqtMxC9igDZyBPOT6OTWSU%2BjoIowo%2BE%3D&a > > > > > > >>> mp;reserv > > > > > > >>>> ed=3D0 > > > > > > >>>> CCodingStandardsSpecification/pull/2 > > > > > > >>>> > > > > > > >>>> The naming rule is mainly for the new module or new file I= MO. > > > > > > >>>> 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 chec= k > 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 implemen= tation > > > > > > >>>>>> [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 arc= h > > > > > > >>>>>> [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=3Dhttps= % > > > > > > >>> 3A%2 > > > > > > >>> F%2F > > > > > > >>> gith > > > > > > >>>>> ub.com%2Ftianocore%2Fedk2- > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > > > > staging%2Fcommit%2Fbba1a11be47dd091734e185afbed73ea75708749& > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > > > > data=3D05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08d > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > > > > aa123e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947 > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > > > > 2732494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > > > > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > > > > ata=3DVq6pJLnn8yJrJhFZn7LfLbZzrtpG4n1VLWgAil6J38U%3D&reserved=3D0 > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps= % > > > > > > >>> 3A%2 > > > > > > >>> F%2F > > > > > > >>> gith > > > > > > >>>>> ub.com%2Ftianocore%2Fedk2- > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > > > > staging%2Fcommit%2F7fccf92a97a6d0618a20f10622220e78b3687906&da > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > > > > ta=3D05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08daa1 > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > > > > 23e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947273 > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > > > > 2494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > > > > 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > > > > =3DxFmvUv58vh4AUAM17Qy9G5jZWFZlK2Ozt3njpG1e8%2BY%3D&reserv > > > > > > >>>>> ed=3D0 > > > > > > >>>>> > > > > > > >>>>> 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 commo= n > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > >