From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (NAM10-MW2-obe.outbound.protection.outlook.com [40.107.94.86]) by mx.groups.io with SMTP id smtpd.web09.15348.1665535926540281989 for ; Tue, 11 Oct 2022 17:52:07 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@amd.com header.s=selector1 header.b=rFhChtCQ; 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.94.86, mailfrom: abner.chang@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mfaK81L9+7AojrO+mo/R04dkB8FiLpJx49X7e7kvG3ql/XdY6gbWolqmZheBdZqj0rZJwS4p1ZaOC5xrzZTXBebWOhkKHDhyCEfln6r4ZMQrGxuchlpDaDzeKl5yryZPZ0eNHveGeJvjf49DdHik3zU87sqU862Xq3Q3dWe6s9rxgLukTynaFwQVXEi+XGAtj/I7NNowJ+DCTz/d5BuDmhNaHi72xwRZ9A0AvoBwZPktDHhrZYvokI65hIJ2v2kTQIF6uZQ1i0QgfDvRii2kiWU7bikzLDXu3MKD9byrqSsjs1rPlAlkUqe580NgUvGntTFkcN/IsvSweV6pVr1A2A== 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=9wse4rRPIStDOZ/sJmCU0zmcO66ddF2CTZl1BZQx1vM=; b=MDELBtjJidrna2NdN9a+YFRXjdhuTBseKFr78ZuNIcOHRLWLhCHGMXfJ+D/dPfXEJRyD42bw4JG88fI33AH2HeTfq6O7Tr4OQhWOGWJCSjqhU8LlPMRqt8n1xR4ePdPTUtMZTv48+NTFyYhJanTtWK3/Q9dT00U82bSI1xgdKtBahVTWK1eVKoTpEuPLQw/BZqlJ4FGBoAph26MuMX29KH4NSZ157AqOznTGjsk7tlqnD/CmHXH7QMQkSgMMELgijez7n7rWp17Yf2rwdiiYPz4oEXrfIu+pyPIGr7RLo++upVCvav8EdiKjfBq7YaRdegreUgOZPV5AG96kU9QkuA== 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=9wse4rRPIStDOZ/sJmCU0zmcO66ddF2CTZl1BZQx1vM=; b=rFhChtCQoV4CWLFEg1as9Ad1D6SFcpV3fS5kZ/lf/YbKjBcBLXyhf2u2/PZDuYkcPE9V043t4wazZKH4pTjylYJaug9HvajsrKYCX4h/8SG/eEQNeorFHsOjPwgVOZjQHVsnRNQokFteqKpMY8li51BJr4lw/surlwLIoUtvVqs= Received: from MN2PR12MB3966.namprd12.prod.outlook.com (2603:10b6:208:165::18) by SN7PR12MB6689.namprd12.prod.outlook.com (2603:10b6:806:273::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.20; Wed, 12 Oct 2022 00:52:03 +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.5709.019; Wed, 12 Oct 2022 00:52:03 +0000 From: "Chang, Abner" To: "Kinney, Michael D" , "Ni, Ray" , "devel@edk2.groups.io" , "quic_llindhol@quicinc.com" , "Attar, AbdulLateef (Abdul Lateef)" , Sunil V L CC: lichao , "Kirkendall, Garrett" , "Grimes, Paul" , "He, Jiangang" , Andrew Fish Subject: Re: [edk2-devel] The principles of EDK2 module reconstruction for archs Thread-Topic: [edk2-devel] The principles of EDK2 module reconstruction for archs Thread-Index: AdjPX4ZZG0rDXS4WTdOIWvoiYOLYcgC9rttQAC2dmIAADxJbkAAiVmtwAABqVrAAMdRUkAARY7IwAAF/rYAABYT70AB0Z6+AAAYqDgAAADksgAAYA9igACxnOYAAAHOkMAAgQPVgADh436AA7UPNIAAAfyYcACXTgHAACbvPAA== Date: Wed, 12 Oct 2022 00:52:03 +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-12T00:51:59Z; 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=da09f8bc-bd20-4a07-a10c-bee1e6df997c; 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_|SN7PR12MB6689:EE_ x-ms-office365-filtering-correlation-id: b60b776c-7a82-41b3-1835-08daabebfa41 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jNjh4tYVnJUzNTX7CJWy1mk6j2RLMWyrb+IHh9k2UU8kIFuyxFKkEpE2EB1Dm76hlG6DhBVZce2d8j/aOzx1lj93ugByNt99O4qRNcbmZ5FxIPgR/OiJ0sHA5N6RwKfA05cbUwxInQHJ90gz4/FmRPCCnrmQEcMmQ/TxBCC/PFsuriLuL5eZE5PVmovTksMtWphnoCIj8xLeH2oHQOFBtpEADrSWo+rJoxjbpiUlQc4cMVd3pjd0ZvEcAaUBc1WqQpInh2KlHD1Rxkeb7VcyGo64HkppBREGMUUog/I2VGSDR1vaosEqQvXQJaPvvU4Vdnzp0ojkDDka8AAexhXes0b+lCVrpsfBOoIHKx3Y8JuR6FB+iXsw/5Ve1HgO2SvjffM/ZS4rpOJHkrpy3SxsM17KuHHNjbRc9ut2wM4N1jswd4MObO4eizkztLFXYN1IhnirUv0puGl/vMtanEhCa+Dl9dwNHeHQKAFzWR+3j0SMi1+y9GspSUAs8bUkkxM5cJpWch9W7qJnIIHIOT8HwIk0Z4lydoZNtDxJTQUQ84CDt6bEnBkcRYsHRomoA6I1icGtS2DlkgOS9Cs0+4cKdy7bmT/vkUjR7EyCLP9s3mnaJl6DGZOOjrAjLZkrvT0S0//bjY6XO90O29rd+xG84JbPgRzxMefVo1L5NWjSlF4Ar/NCNcJDK8cdyi1ZUWFKekxLSJNjMFkIv607H51LE46PEaNK3LjUsRcvLdIxYtVxGALoQnC0WOH3IbAvpCxyFzKQGtXDGiM49k87KkXaVktbIdL8FNauvTodE5/Njwdj0QBzT5k4/wISzhG6tk+BlDadEk1KBB6fivBT2UySpA== 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)(346002)(376002)(39860400002)(136003)(366004)(451199015)(8936002)(66899015)(33656002)(55016003)(83380400001)(38070700005)(38100700002)(7696005)(110136005)(86362001)(52536014)(5660300002)(6506007)(41300700001)(64756008)(186003)(122000001)(66946007)(30864003)(316002)(53546011)(478600001)(4326008)(2906002)(26005)(45080400002)(166002)(66556008)(66476007)(9686003)(966005)(66446008)(19627235002)(54906003)(8676002)(76116006)(71200400001)(579004)(559001);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?DzXmaef8diP7UGLZk0+G6+BI51u6/TxlzzyQUYGaCt0uJsP2ksYGrTCB5/ll?= =?us-ascii?Q?Veg17NcBbKh3GGJ31j89Ymm4cNpQpg99NqBrCJYFSN3VEYXJVlSE9MnN+/rk?= =?us-ascii?Q?/xpHwnhhCQfN9Hp/nqG6IssxYQuWCSMP1y8vMlsnkJ0WTA2n43NwZsPfhlX9?= =?us-ascii?Q?1Fv4AO+YjQkJ3if6d0avOMKBd6Qobi4OOSuElRM+AzX9afl+c93w4fcahjRC?= =?us-ascii?Q?OwWMoDsmt5N7UA8UldDWxVhDbg2Dc3/Zdv9lKCX4CTxQUd9LCeDQ5FPFJhNr?= =?us-ascii?Q?vi8kKuz7PzsCdSymTpUFcuMx70KhzttJI4FFeiVGyfUCiduGW03bUCDPIipa?= =?us-ascii?Q?vdpQ9C8iYAg/au6Fq4l8M/l8Ox33muzvjbA45pmUojM0OrRfp8o0ExRcsDyc?= =?us-ascii?Q?VMzOnQ2Gs1sYob73PpiUR1lBrGarjqZZm4RGvsIdE3mP5b3CUgh5pLp39xYb?= =?us-ascii?Q?LeWw/p1wR6ealvYgRZ62u3tFDG1pmf2q3opeSWCYanPvBTO0CT8awCTylojN?= =?us-ascii?Q?r1kcoHsExJMteB4zExuUHi/AHih9P3Y0WvCuVxQ+bRsBDYB40Df5PjNFr6Xf?= =?us-ascii?Q?CN/varx5h8fXhaCLva3YzL6lVXRp+8p2kwBQnn/ptDVffroXyC30bM1ndlZV?= =?us-ascii?Q?A0CnYswqmVuCjx5TF8II9buOq8XQCHkARvoREr/PTEQC5bgVkuC3s/0+WPf+?= =?us-ascii?Q?ZSEn+keexRhvKHMka3tsaI3dhx0RLL+Tdl7r763JcS+5OrjaN6J23+9ZRgmh?= =?us-ascii?Q?gOD+zrRncrWAshK99XgbRPHjLloIjPUWgfKiixqHOiyrK5nqwj8Vm+YnqA0B?= =?us-ascii?Q?hUKQ+xqVpi/xqBqEJHQkHG9srKyaJ4U+OLQxvX1NTq3smR34HEIg3TfcgQS0?= =?us-ascii?Q?bKDopdmP193cn5Pbx3ShttA+sQBFlRIyjKrhYYYnTZ8uy6ccldJzYStHXgWS?= =?us-ascii?Q?eDs5olM+yWZXLx9w9Aagg28Pmci9INbqGHNFSRAqNW67WE5pEvyd/+My2nrr?= =?us-ascii?Q?HLrBsl4xqVbkS3fGrWoBB+HbREbLsVAK7tKnYgfrFC/7pSUJ6tpcK785tjKz?= =?us-ascii?Q?RnP5fFBG8lSsCPMsuueIsAr0SIMgfE4aevdu4TnfJfMPd+ybbHt441WOdNtH?= =?us-ascii?Q?pDYeQ/ajFeA1tShn1qPEDEnpQjIkIdRCnUHOVZvuH3FYIlBjf26LvnwXXGzT?= =?us-ascii?Q?hFj919MlUTZ1g4l77HxBMOmtF5sWzrXqtVyNDRNmv06t8CzNcEJt9mHREUVf?= =?us-ascii?Q?oUqaSIXuzSuu+uryUI2mosXMMRDd+HAa70Yti1CVDmNkJdDataebjr4+Rewt?= =?us-ascii?Q?gt7dKbD5xzSRZn529gKX0+6QFO6m5VgQ/8rhD1KeALqAwKmSq3b6wAmksllG?= =?us-ascii?Q?sI21yDYy0LNExmrm7phwlidEdhy49CdfwRneYv5KUsE5zB609MMY9kSMz8oo?= =?us-ascii?Q?FDjLYIG9VWjbk5xLmxtcK6/GCEbCPKBeRhvfXx+hdz8dkCZu3Jro55l3yCjJ?= =?us-ascii?Q?yxGUuplQ16aeJXJnBuQFSruxDCDoNHISF7Pp2DOv6RS3iUpvsYL7xSceAAQV?= =?us-ascii?Q?EvMMw7l2b/+bK9L1ImNgaLczLPr0iYa6sFUAJ0Js?= 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: b60b776c-7a82-41b3-1835-08daabebfa41 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2022 00:52:03.0424 (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: 0WryQvk5ChO9vU1jJNLg5VwzU28mHOLIJIHzgvlbkvG6k/nkhFBITMMp9QacbjxqXcf21nQX7AHnLuBhrQbN1w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB6689 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_MN2PR12MB3966302441AEEFB0F28737BAEA229MN2PR12MB3966namp_" --_000_MN2PR12MB3966302441AEEFB0F28737BAEA229MN2PR12MB3966namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [AMD Official Use Only - General] I was thinking to remove '_' from edkII coding standard if there is no use = case or rare people like it appears in file/dir name. Abner From: Kinney, Michael D Sent: Wednesday, October 12, 2022 4:16 AM To: Chang, Abner ; Ni, Ray ; devel@e= dk2.groups.io; quic_llindhol@quicinc.com; Attar, AbdulLateef (Abdul Lateef)= ; Sunil V L ; Kinney,= Michael D Cc: lichao ; Kirkendall, Garrett ; Grimes, Paul ; He, Jiangang ; Andrew Fish Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for = archs [AMD Official Use Only - General] Caution: This message originated from an External Source. Use proper cautio= n when opening attachments, clicking links, or responding. I do not have a strong opinion either way. Some searching indicates there is some debate between use of spaces, unders= cores, and dashes in filenames. The filename/dirname requirements for EDK II allow '_' and '-' as long as t= hey are not the first or last character. Spaces ' ' are not allowed. [A-Za-z][_A-Za-z0-9-]*[A-Za-z0-9]+ Mike From: Chang, Abner > Sent: Monday, October 10, 2022 7:21 PM To: Ni, Ray >; Kinney, Michael D = >; devel@edk2= .groups.io; quic_llindhol@quicinc.com; Attar, AbdulLateef (Abdul Lateef) >; Sunil V L > Cc: lichao >; Kirkendall, Gar= rett >; Grime= s, Paul >; He, Jiangang >; Andrew Fish > Subject: Re: [edk2-devel] The principles of EDK2 module reconstruction for = archs [AMD Official Use Only - General] Removing '_' seems make the folder hard to read, but not too bad to me thou= gh. I am fine with removing '_'. Leif and Mike, how do you think? Ex: Riscv64Ia32X64 compares Riscv64_Ia32_X64. ArmAArch64 compares to Arm_AArch64. Abner Get Outlook for Android ________________________________ From: Ni, Ray > Sent: Tuesday, October 11, 2022 9:51:24 AM To: Chang, Abner >; Kinney,= Michael D >;= devel@edk2.groups.io >; quic_llindhol@quicinc.com >= ; Attar, AbdulLateef (Abdul Lateef) >; Sunil V L > Cc: lichao >; Kirkendall, Gar= rett >; Grime= s, 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 cautio= n when opening attachments, clicking links, or responding. Abner, Mike, Leif, "Ia32_X64" is the first case in edk2 that underscore "_" is used as part of= file path. Shall we use "Ia32X64" (removing "_")? I know that Sunil is following the guideline. https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fedk2.gr= oups.io%2Fg%2Fdevel%2Fmessage%2F94912%3Fp%3D%252C%252C%252C20%252C0%252C0%2= 52C0%253A%253Arecentpostdate%252Fsticky%252C%252CUefiCpuPkg%252FCpuTimerLib= %252C20%252C2%252C0%252C94233015&data=3D05%7C01%7CAbner.Chang%40amd.com= %7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%= 7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj= oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3D5wOiTA= rZyySLos4A%2FQHOC3gryUIZ8K4SgNxeTwfANMY%3D&reserved=3D0 Thanks, Ray > -----Original Message----- > From: Chang, Abner > > Sent: Thursday, October 6, 2022 4: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, G= arrett > >; Grimes, = Paul >; He, > Jiangang >; Andrew Fish <= afish@apple.com> > Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction fo= r > archs > > [AMD Official Use Only - General] > > Here is the update of the Wiki page for the consistency with edk2 C Codin= g > Standard Spec. > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithu= b.com%2Fchangab%2Ftianocore.github.io%2Fwiki%2FThe-Guidelines-of-&data= =3D05%7C01%7CAbner.Chang%40amd.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd= 8961fe4884e608e11a82d994e183d%7C0%7C0%7C638010498938218357%7CUnknown%7CTWFp= bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%= 7C3000%7C%7C%7C&sdata=3Di5RSe41cuzD48VB32KeG0M3Vp7T%2FEqe3ncKNfGCjfIU%3= D&reserved=3D0 > Reconstruct-EDK-II-Modules-for-Processor-Architectures-and-Vendors'- > Implementation > > Thanks > Abner > > > -----Original Message----- > > From: Chang, Abner > > Sent: Wednesday, October 5, 2022 1:39 PM > > To: Kinney, Michael D >; > devel@edk2.groups.io; > > quic_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] > > > > PR updated > > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgit= hub.com%2Ftianocore-docs%2Fedk2-&data=3D05%7C01%7CAbner.Chang%40amd.com= %7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%= 7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj= oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3DYDYXOD= grQhuLlP8DTsLr%2F4ct2JH3aw8y2SPg8tk5fgg%3D&reserved=3D0 > > CCodingStandardsSpecification/pull/2/commits. Please check it. > > > > Thanks > > Abner > > > > > -----Original Message----- > > > From: Kinney, Michael D > > > > Sent: Tuesday, October 4, 2022 10:18 PM > > > To: Chang, Abner >; d= evel@edk2.groups.io; > > > quic_llindhol@quicinc.com; Ni, Ray = >; Attar, > > > AbdulLateef (Abdul Lateef) >; Sunil V L > > > >; Kinney, = Michael D > > > > > > > Cc: lichao >; Kirkendal= l, Garrett > > > >; Grim= es, Paul >; > > He, > > > Jiangang >; Andrew Fi= sh > > > > Subject: RE: [edk2-devel] The principles of EDK2 module reconstructio= n > > > 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 Specificat= ion. > > > > > > We want documents published from tianocore-docs to support > standalone > > > formats such as PDF and if there is a link in one of those documents, > > > we want to know that it is a permanent link. I am concerned we may > > > reorganize Wiki pages and links in PDF would become stale. > > > > > > Links from Wiki to specs makes sense. > > > > > > Mike > > > > > > > -----Original Message----- > > > > From: Chang, Abner = > > > > > Sent: Tuesday, October 4, 2022 7:05 AM > > > > To: Kinney, Michael D >; > > > > devel@edk2.groups.io; quic_llindhol@qu= icinc.com; Ni, Ray > > > > >; Attar, AbdulLateef (Ab= dul Lateef) > > > > >; Suni= l V L > > > > > Cc: lichao >; Kirkend= all, Garrett > > > > >; Gr= imes, Paul > >; > > > > He, Jiangang >; And= rew Fish > > > > > > Subject: RE: [edk2-devel] The principles of EDK2 module > > > > reconstruction for archs > > > > > > > > [AMD Official Use Only - General] > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Kinney, Michael D > > > > > > Sent: Tuesday, October 4, 2022 12:54 AM > > > > > To: devel@edk2.groups.io; Chang, Abn= er >; > > > > > quic_llindhol@quicinc.com; Ni, = Ray >; Attar, > > > > > AbdulLateef (Abdul Lateef) >; Sunil V L > > > > > >; Kinn= ey, Michael D > > > > > > > > > > > Cc: lichao >; Kirke= ndall, Garrett > > > > > >; = Grimes, Paul > > >; > > > > > He, Jiangang >; A= ndrew Fish > > > > > > > > Subject: RE: [edk2-devel] The principles of EDK2 module > > > > > reconstruction for archs > > > > > > > > > > Caution: This message originated from an External Source. Use > > > > > proper caution when opening attachments, clicking links, or > responding. > > > > > > > > > > > > > > > Hi Abner, > > > > > > > > > > responses below. > > > > > > > > > > Mike > > > > > > > > > > > -----Original Message----- > > > > > > From: devel@edk2.groups.io > On Behalf Of > > > > > > Chang, Abner via groups.io > > > > > > Sent: Sunday, October 2, 2022 10:37 PM > > > > > > To: Kinney, Michael D >; > > > > > > devel@edk2.groups.io; quic_llindho= l@quicinc.com; Ni, Ray > > > > > > >; Attar, AbdulLateef= (Abdul Lateef) > > > > > > >; = Sunil V L > > > > > > > > > > > > > Cc: lichao >; Kir= kendall, Garrett > > > > > > >= ; Grimes, Paul > > > > > > >; > > > > > He, > > > > > > Jiangang >; And= rew Fish > > > > > > > Subject: Re: [edk2-devel] The principles of EDK2 module > > > > > > reconstruction for archs > > > > > > > > > > > > [AMD Official Use Only - General] > > > > > > > > > > > > Mike, > > > > > > Agree. This can be mentioned on the Wiki page. Also, this would > > > > > > require the discussion between maintainer and contributor. I > > > > > > would say > > > > > maintainer has the responsibility to make sure an arch folder is > > > > > only created when necessary. > > > > > > > > > > Agreed > > > > Ok, I will update Directory and file names section. > > > > > > > > > > > > > > > > > Do you agree with the arch concatenate solution for arch folder= ? > > > > > > That > > > > > means IA32_X64 instead of X86 (I am fine with this)? > > > > > > > > > > Yes > > > > > > > > > > > However, there is one scenario. Assume there were two arch > > > > > > folders > > > > > > IA32_X64 and RISCV64. Then ARM shares the code with IA32_X64, > we > > > > > > may > > > > > rename IA32_X64 to IA32_X64_ARM. > > > > > > Although the directory naming is not real a problem to the > > > > > > build, a separate ARM folder seems easier? Or we can just allow > > > > > > this kind of folder > > > > > naming structure, however we let maintainer to make the decision? > > > > > > > > > > I would let the maintainer make the decision. For your example, > > > > > another approach may be to move the IA32_X64 content up a level s= o > > > > > 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 standar= d spec? > > > > > > > > Abner > > > > > > > > > > > > > > > > > > > > > Abner > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Kinney, Michael D > > > > > > > > Sent: Monday, October 3, 2022 1:18 PM > > > > > > > To: Chang, Abner >; > > devel@edk2.groups.io; > > > > > > > quic_llindhol@quicinc.com; = Ni, Ray >; Attar, > > > > > > > AbdulLateef (Abdul Lateef) >; Sunil > > > > > > > V L >; Kinney, Michael D > > > > > > > > > > > > > > > Cc: lichao >; K= irkendall, Garrett > > > > > > > >; Grimes, Paul > > > > > > > >; He, Jianga= ng > >; > > > > > > > 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_lli= ndhol@quicinc.com; Ni, Ray > > > > > > > > >; Attar, AbdulLa= teef (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%2F > > > > > ed > > > > > > > k > > > > > > > 2 > > > > > > > > > > > > > > > > > > .groups.io%2Fg%2Fdevel%2Fmessage%2F94567&data=3D05%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=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 modifier for > X86, > > > > > RISC-V > > > > > > > and ARM. > > > > > > > > CpuDxeAmd.inf // Separate INF for AM= D. > > > > > > > > > > > > > > > > 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; qu= ic_llindhol@quicinc.com; > > > > > > > > > Chang, Abner >; Ni, Ray > > > > > > > > > >; Attar, Abdul= Lateef (Abdul Lateef) > > > > > > > > > >; Sunil V L > > > > > > > > > >; Kinney, Michael D > > > > > > > > > > > > > > > > > > > Cc: lichao = >; Kirkendall, Garrett > > > > > > > > > >; Grimes, Paul > > > > > > > > > >; He, Ji= angang > > >; > > > > > > > > > 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 o= r > > > > > > > > > 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, wha= t > > > > > > > > > would be the suggested directory name for "32" and "64". > > > > > > > > > Or do we want to require this type of difference to alway= s > > > > > > > > > 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 >; At= tar, 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 > > > > > > > > > > >> >; H= e, 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= =3Dh > > > > > > > > > > >> tt > > > > > > > > > > >> ps%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= =3D > > > > > > > > > > >>> ht > > > > > > > > > > >>> tps% > > > > > > > > > > >>> 3A%2 > > > > > > > > > > >>> F%2F > > > > > > > > > > >>> gith > > > > > > > > > > >>> ub.com%2Ftianocore-docs%2Fedk2- > > > > > > > > > > >>> > CCodingStandardsSpecification%2Fpull%2F2%23pullreque > > > > > > > > > > >>> st > > > > > > > > > > >>> revi > > > > > > > > > > >>> ew- > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > 1124763311&data=3D05%7C01%7CAbner.Chang%40amd.com%7Cd825e24 > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > 8625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82d994e183d%7C0 > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > %7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > C > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > 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. W= e > > > > > > > > > > >>>> 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= =3D > > > > > > > > > > >>> ht > > > > > > > > > > >>> tps% > > > > > > > > > > >>> 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 ne= w > 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 t= o > > > > > > > > > > >>>>>> that arch > > > > > > > folder? > > > > > > > > > > >>>>>> It will > > > > > > > > > > >>>>> break existing platforms a lot. > > > > > > > > > > >>>>>> > > > > > > > > > > >>>>>> * Create the arch folder for the new introd= uced > > arch > > > > > > > > > > >>>>>> [Ray] I agree. But if we don't create arch folde= r > > > > > > > > > > >>>>>> for existing arch > > > > > > > > > > >>>>> implementation, the pkg layout will be a mess. > > > > > > > > > > >>>>>> > > > > > > > > > > >>>>>> [Ray] Hard for me to understand all the principl= es > 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= =3D > > > > > > > > > > >>> ht > > > > > > > > > > >>> tps% > > > > > > > > > > >>> 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= =3D > > > > > > > > > > >>> ht > > > > > > > > > > >>> tps% > > > > > > > > > > >>> 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 o= nly 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > > > > > > --_000_MN2PR12MB3966302441AEEFB0F28737BAEA229MN2PR12MB3966namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[AMD Officia= l Use Only - General]

 

I was thinking to remove ‘_’ from edkII = coding standard if there is no use case or rare people like it appears in f= ile/dir name.

 

Abner

 

From: Kinney, Michael D <michael.d.kinney@= intel.com>
Sent: Wednesday, October 12, 2022 4:16 AM
To: Chang, Abner <Abner.Chang@amd.com>; Ni, Ray <ray.ni@int= el.com>; devel@edk2.groups.io; quic_llindhol@quicinc.com; Attar, AbdulLa= teef (Abdul Lateef) <AbdulLateef.Attar@amd.com>; Sunil V L <sunilv= l@ventanamicro.com>; Kinney, Michael D <michael.d.kinney@intel.com>= ;
Cc: lichao <lichao@loongson.cn>; Kirkendall, Garrett <Garre= tt.Kirkendall@amd.com>; Grimes, Paul <Paul.Grimes@amd.com>; He, Ji= angang <Jiangang.He@amd.com>; Andrew Fish <afish@apple.com>
Subject: RE: [edk2-devel] The principles of EDK2 module reconstructi= on for archs

 

[AMD Official Use Only - General]<= /o:p>

 

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

 

I do not have a strong opinion either way. 

 

Some searching indicates there is some debate betwee= n use of spaces, underscores, and dashes in filenames.

 

The filename/dirname requirements for EDK II allow &= #8216;_’ and ‘-‘ as long as they are not the first or las= t character.  Spaces ‘ ‘ are not allowed.

 

[A-Za-z][_A-Za-z0-9-]*[A-= Za-z0-9]+

 

Mike

 

 

[AMD Official Use Only - General]<= /o:p>

 

Removing '_' seems make the folder hard to read, but not too bad to me= though. I am fine with removing '_'. 

Leif and Mike, how do you think?

 

Ex:

Riscv64Ia32X64 compares Riscv64_Ia32_X64.

ArmAArch64 compares to Arm_AArch64.

 

Abner=

Caution: This message originated from an External So= urce. Use proper caution when opening attachments, clicking links, or respo= nding.


Abner, Mike, Leif,
"Ia32_X64" is the first case in edk2 that underscore "_"= ; is used as part of file path.
Shall we use "Ia32X64" (removing "_")?

I know that Sunil is following the guideline.
https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fedk2.g= roups.io%2Fg%2Fdevel%2Fmessage%2F94912%3Fp%3D%252C%252C%252C20%252C0%252C0%= 252C0%253A%253Arecentpostdate%252Fsticky%252C%252CUefiCpuPkg%252FCpuTimerLi= b%252C20%252C2%252C0%252C94233015&amp;data=3D05%7C01%7CAbner.Chang%40am= d.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d= %7C0%7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL= CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata= =3D5wOiTArZyySLos4A%2FQHOC3gryUIZ8K4SgNxeTwfANMY%3D&amp;reserved=3D0

Thanks,
Ray

> -----Original Message-----
> From: Chang, Abner <Abner.Ch= ang@amd.com>
> Sent: Thursday, October 6, 2022 4:37 PM
> To: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io;
> quic_llindhol@quicinc.com= ; Ni, Ray <ray.ni@intel.com&= gt;; Attar, AbdulLateef
> (Abdul Lateef) <AbdulL= ateef.Attar@amd.com>; Sunil V L
> <sunilvl@ventanamicro.c= om>
> Cc: lichao <lichao@loongson.c= n>; Kirkendall, Garrett
> <Garrett.Kirkendall@a= md.com>; Grimes, Paul <Pau= l.Grimes@amd.com>; He,
> Jiangang <Jiangang.He@amd.co= m>; Andrew Fish <afish@apple.c= om>
> 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 Co= ding
> Standard Spec.
> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.= com%2Fchangab%2Ftianocore.github.io%2Fwiki%2FThe-Guidelines-of-&amp;dat= a=3D05%7C01%7CAbner.Chang%40amd.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3d= d8961fe4884e608e11a82d994e183d%7C0%7C0%7C638010498938218357%7CUnknown%7CTWF= pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D= %7C3000%7C%7C%7C&amp;sdata=3Di5RSe41cuzD48VB32KeG0M3Vp7T%2FEqe3ncKNfGCj= fIU%3D&amp;reserved=3D0
> 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 <michael.d.kinney@intel.com>;
> devel@edk2.groups.io;
> > quic_llindhol@quicin= c.com; Ni, Ray <ray.ni@intel.com= >; Attar, AbdulLateef
> > (Abdul Lateef) <A= bdulLateef.Attar@amd.com>; Sunil V L
> > <sunilvl@ventanami= cro.com>
> > Cc: lichao <lichao@loong= son.cn>; Kirkendall, Garrett
> > <Garrett.Kirkend= all@amd.com>; Grimes, Paul <Paul.Grimes@amd.com>;
> He,
> > Jiangang <Jiangang.He@a= md.com>; Andrew Fish <afish@ap= ple.com>
> > Subject: RE: [edk2-devel] The principles of EDK2 module reconstru= ction for
> > archs
> >
> > [AMD Official Use Only - General]
> >
> > PR updated
> > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.= com%2Ftianocore-docs%2Fedk2-&amp;data=3D05%7C01%7CAbner.Chang%40amd.com= %7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%= 7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj= oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=3DYD= YXODgrQhuLlP8DTsLr%2F4ct2JH3aw8y2SPg8tk5fgg%3D&amp;reserved=3D0
> > CCodingStandardsSpecification/pull/2/commits. Please check it. > >
> > Thanks
> > Abner
> >
> > > -----Original Message-----
> > > From: Kinney, Michael D <michael.d.kinney@intel.com>
> > > Sent: Tuesday, October 4, 2022 10:18 PM
> > > To: Chang, Abner <= Abner.Chang@amd.com>; devel@edk2.groups.io;
> > > quic_llindhol@q= uicinc.com; Ni, Ray <ray.ni@inte= l.com>; Attar,
> > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com>; Sunil V L
> > > <sunilvl@vent= anamicro.com>; Kinney, Michael D
> > > <michael.d.= kinney@intel.com>
> > > Cc: lichao <lichao@= loongson.cn>; Kirkendall, Garrett
> > > <Garrett.Ki= rkendall@amd.com>; Grimes, Paul <Paul.Grimes@amd.com>;
> > He,
> > > Jiangang <Jiangang= .He@amd.com>; Andrew Fish <afi= sh@apple.com>
> > > Subject: RE: [edk2-devel] The principles of EDK2 module reco= nstruction
> > > for archs
> > >
> > > Caution: This message originated from an External Source. Us= e proper
> > > caution when opening attachments, clicking links, or respond= ing.
> > >
> > >
> > > I would not add link to Wiki from EDK II C Coding Standard S= pecification.
> > >
> > > We want documents published from tianocore-docs to support > standalone
> > > formats such as PDF and if there is a link in one of those d= ocuments,
> > > we want to know that it is a permanent link.  I am conc= erned 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 <Abner.Chang@amd.com>
> > > > Sent: Tuesday, October 4, 2022 7:05 AM
> > > > To: Kinney, Michael D <michael.d.kinney@intel.com>;
> > > > devel@edk2.grou= ps.io; quic_llindhol@quicinc.com; Ni, Ray
> > > > <ray.ni@intel.co= m>; Attar, AbdulLateef (Abdul Lateef)
> > > > <AbdulL= ateef.Attar@amd.com>; Sunil V L <sunilvl@ventanamicro.com>
> > > > Cc: lichao <li= chao@loongson.cn>; Kirkendall, Garrett
> > > > <Garre= tt.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
> > > >
> > > > [AMD Official Use Only - General]
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Kinney, Michael D <michael.d.kinney@intel.com>
> > > > > Sent: Tuesday, October 4, 2022 12:54 AM
> > > > > To: devel@= edk2.groups.io; Chang, Abner <Abner.Chang@amd.com>;
> > > > > quic_= llindhol@quicinc.com; Ni, Ray <r= ay.ni@intel.com>; Attar,
> > > > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com>; Sunil V L
> > > > > <su= nilvl@ventanamicro.com>; Kinney, Michael D
> > > > > <= michael.d.kinney@intel.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 m= odule
> > > > > reconstruction for archs
> > > > >
> > > > > Caution: This message originated from an External = Source. Use
> > > > > proper caution when opening attachments, clicking = links, or
> responding.
> > > > >
> > > > >
> > > > > Hi Abner,
> > > > >
> > > > > responses below.
> > > > >
> > > > > Mike
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: devel@edk2.groups.io <devel= @edk2.groups.io> On Behalf Of
> > > > > > Chang, Abner via groups.io
> > > > > > Sent: Sunday, October 2, 2022 10:37 PM
> > > > > > To: Kinney, Michael D <michael.d.kinney@intel.com>;
> > > > > > devel= @edk2.groups.io; quic_llindhol@quicinc.com; Ni, Ray
> > > > > > <ray.n= i@intel.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
> > > > > > <Pa= ul.Grimes@amd.com>;
> > > > > He,
> > > > > > Jiangang <Jiangang.He@amd.com>; Andrew Fish <afish@apple.com>
> > > > > > Subject: Re: [edk2-devel] The principles of E= DK2 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 soluti= on 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 cod= e with IA32_X64,
> we
> > > > > > may
> > > > > rename IA32_X64 to IA32_X64_ARM.
> > > > > > Although the directory naming is not real a p= roblem 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 mak= e the decision?
> > > > >
> > > > > I would let the maintainer make the decision. = ; For your example,
> > > > > another approach may be to move the IA32_X64 conte= nt 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.&= nbsp; I think having
> > > > > some flexibility in the guidelines is very benefic= ial.  The main
> > > > > goal is for consistency when a specific guideline = is followed.
> > > > I think we can have the naming rules in the edk2 C codi= ng standard
> > > > spec and
> > > put these guidelines on the Wiki page.
> > > > Is that ok to have a link to Wiki page in the edk2 C co= ding standard spec?
> > > >
> > > > Abner
> > > >
> > > > >
> > > > > >
> > > > > > Abner
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Kinney, Michael D <michael.d.kinney@intel.com>
> > > > > > > Sent: Monday, October 3, 2022 1:18 PM > > > > > > > To: Chang, Abner <Abner.Chang@amd.com>;
> > devel@edk2.groups.io;=
> > > > > > > quic_llindhol@quicinc.com; Ni, Ray <ray.ni@intel.com>; Attar,
> > > > > > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@amd.com>; Su= nil
> > > > > > > V L <sunilvl@ventanamicro.com>; Kinney, Michael D
> > > > > > > <michael.d.kinney@intel.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
> > > > > > >
> > > > > > > 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 or= ganization and long
> > > > > > > term maintenance of the component.
> > > > > > >
> > > > > > > Mike
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Chang, Abner <Abner.Chang@amd.com>
> > > > > > > > Sent: Sunday, October 2, 2022 8:13 = PM
> > > > > > > > To: Kinney, Michael D <michael.d.kinney@intel.com>;<= br> > > > > > > > > devel@edk2.groups.io; quic_llindhol@quicinc.com; Ni, Ray
> > > > > > > > <ray.ni@intel.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.Gr= imes@amd.com>;
> > > > > > > He,
> > > > > > > > Jiangang <Jiangang.He@amd.com>; Andrew Fish
> > > > > > > > <afish@apple.com>
> > > > > > > > Subject: RE: [edk2-devel] The princ= iples of EDK2 module
> > > > > > > > reconstruction for archs
> > > > > > > >
> > > > > > > > [AMD Official Use Only - General] > > > > > > > >
> > > > > > > > Hi Mike and Leif,
> > > > > > > > First of all, we don't use arch fol= der if the module is
> > > > > > > > mainly for a specific arch in obvio= usly. So we will  have
> > > > > > > > both common and arch-specific
> > > > > > > files constructed under module/library r= oot.
> > > > > > > >
> > > > > > >
> > > > >
> > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F > > > > > ed
> > > > > > > k
> > > > > > > 2
> > > > > > >
> > > > >
> > >
> > > .groups.io%2Fg%2Fdevel%2Fmessage%2F94567&amp;data=3D05%7= C01%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&amp;sdata=3DeiLOC0G9WZWKqm2ALcAiKr7SPBP5AgDdAxogHlv5pI
> > > > > > > M%3D&amp;r
> > > > > > > > eserved=3D0
> > > > > > > > SmmCpuFeatureLib\Ia32
> > > > > > > > SmmCpuFeatureLib\X64
> > > > > > > > SmmCpuFeatureLib\SmmCpuFeatureLib.c=
> > > > > > > > SmmCpuFeatureLib\SmmCpuFeatureLibCo= mmon.c
> > > > > > > > SmmCpuFeatureLib\IntelSmmCPuFeature= sLib
> > > > > > > > SmmCpuFeatureLib\AmdlSmmCPuFeatures= Lib
> > > > > > > >
> > > > > > > >
> > > > > > > > > > Could we concatenate arch= itectures?
> > > > > > > > > > I.e. AARCH64_ARM, IA32_X6= 4, AARCH64_RISCV64... ?
> > > > > > > > Looks like below?
> > > > > > > >
> > > > > > > > CpuDxe\IA32_X64\IA32\abc.nasm
> > CpuDxe\IA32_X64\X64\abc.nasm
> > > > > > > > CpuDxe\IA32_X64\CpuDxe.c CpuDxe\IA3= 2_X64\AmdCpuDxe.c
> > > > > > > > CpuDxe\IA32_X64\IntelCpuDxe.c CpuDx= e\RiscV64\CpuDxe.c
> > > > > > > > CpuDxe\ARM\CpuDxe.c CpuDxe\
> > > > > > > >      =           CpuDxeCommon.c = // If required.
> > > > > > > >      =            CpuDxe.inf&nbs= p;            &= nbsp; // Use INF section arch modifier for
> X86,
> > > > > RISC-V
> > > > > > > and ARM.
> > > > > > > >      =            CpuDxeAmd.inf&= nbsp;       // Separate INF for AMD.
> > > > > > > >
> > > > > > > > Seems ok, but is AARCH64_RISCV64 a = real case?  Or it means
> > > > > > > > we can create a folder "AARCH6= 4_RISCV64" when there are
> some
> > > > > > > > common
> > > > > files
> > > > > > > shared by AARCH64 and RISCV64?
> > > > > > > >
> > > > > > > > For the 32/64 bit support, it can s= till stay under module
> > > > > > > > root and don't need to assign a fol= der for them unless the
> > > > > > > > arch has the different
> > > > > > > implementation.
> > > > > > > > Regards,
> > > > > > > > Abner
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Kinney, Michael D <michael.d.kinney@intel.com&= gt;
> > > > > > > > > Sent: Saturday, October 1, 202= 2 2:52 AM
> > > > > > > > > To: devel@edk2.groups.io; quic_llindhol@quicinc.com;=
> > > > > > > > > Chang, Abner <Abner.Chang@amd.com>; Ni, Ray
> > > > > > > > > <ray.ni@intel.com>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > <AbdulLateef.Attar@amd.com>; Sunil V L
> > > > > > > > > <sunilvl@ventanamicro.com>; Kinney, Michael D
> > > > > > > > > <michael.d.kinney@intel.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
> > > > > > > > >
> > > > > > > > > Caution: This message originat= ed from an External Source.
> > > > > > > > > Use proper caution when openin= g attachments, clicking
> > > > > > > > > links, or
> > > > > responding.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Hi Leif,
> > > > > > > > >
> > > > > > > > > Concatenation is a good idea.&= nbsp; Makes it more obvious and
> > > > > > > > > can be easily adopted for new = CPU archs.
> > > > > > > > >
> > > > > > > > > There is an additional case wh= ere 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 bec= ause Ebc adapts to 32-bit or
> > > > > > > > > 64-bit depending on the CPU ty= pe the EBC Interpreter is
> running.
> > > > > > > > >
> > > > > > > > > MdePkg/Library/BaseSafeIntLib/=
> > > > > > > > >   BaseSafeIntLib.inf=
> > > > > > > > >   SafeIntLib.c
> > > > > > > > >   SafeIntLib32.c
> > > > > > > > >   SafeIntLib64.c
> > > > > > > > >   SafeIntLibEbc.c > > > > > > > > >
> > > > > > > > > Should we add "32" a= nd "64" as supported suffices in file
> names?
> > > > > > > > >
> > > > > > > > > If we wanted to put type conte= nt into a subdirectory, what
> > > > > > > > > would be the suggested directo= ry name for "32" and "64".
> > > > > > > > > Or do we want to require this = type of difference to always
> > > > > > > > > be files in top level director= y of
> > > > > > > the modules/library?
> > > > > > > > >
> > > > > > > > > Best regards,
> > > > > > > > >
> > > > > > > > > Mike
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > -----Original Message----= -
> > > > > > > > > > From: devel@edk2.groups.io <devel@edk2.groups.io> On
> > > > > > > > > > Behalf Of Leif Lindholm > > > > > > > > > > Sent: Friday, September 3= 0, 2022 9:09 AM
> > > > > > > > > > To: devel@edk2.groups.io; Kinney, Michael D
> > > > > > > > > > <michael.d.kinney@intel.com>; Chang, Abner > > > > > > > <Abner.Chang@amd.com>;
> > > > > > > > > > Ni, Ray <ray.ni@intel.com>; Attar, AbdulLateef (Abdul<= br> > > > > > > > > > > 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 > > > > > > > <a= fish@apple.com>
> > > > > > > > > > Subject: Re: [edk2-devel]= The principles of EDK2 module
> > > > > > > > > > reconstruction for archs<= br> > > > > > > > > > >
> > > > > > > > > > I agree similar things wi= ll certainly happen for
> > > > > > > > > > ARM/AARCH64, which will p= robably 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<= br> > > > > > > > which don't.
> > > > > > > > > >
> > > > > > > > > > Could we concatenate arch= itectures?
> > > > > > > > > > I.e. AARCH64_ARM, IA32_X6= 4, AARCH64_RISCV64... ?
> > > > > > > > > >
> > > > > > > > > > /
> > > > > > > > > >    &n= bsp; Leif
> > > > > > > > > >
> > > > > > > > > > On 2022-09-30 08:28, Mich= ael D Kinney wrote:
> > > > > > > > > > > Hi Abner,
> > > > > > > > > > >
> > > > > > > > > > > One comment is on ad= ding a new CPU type dir name of
> 'X86'
> > > > > > > > > > > for content that is = common for IA32/X64.
> > > > > > > > > > >
> > > > > > > > > > > I can imagine a simi= lar case for ARM/AARCH64 and for
> > > > > > > > > > > the RISCV (32, 64, 1= 28) cases.
> > > > > > > > > > >
> > > > > > > > > > > I think I would pref= er to drop X86 and if there are
> > > > > > > > > > > files that are commo= n to multiple CPU architectures
> > > > > > > > > > > then they are consid= ered 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 Me= ssage-----
> > > > > > > > > > >> From: Chang, Abn= er <Abner.Chang@amd.com> > > > > > > > > > > >> Sent: Friday, Se= ptember 30, 2022 12:11 AM
> > > > > > > > > > >> To: Ni, Ray <= ray.ni@intel.com>; Attar, AbdulL= ateef
> > > > > > > > > > >> (Abdul
> > > > > > > > > > >> Lateef) <AbdulLateef.Attar@amd.com>;= Sunil V L
> > > > > > > > > > >> <sunilvl@ventanamicro.com>; devel@edk2.groups.io;
> > > > > > > > > > >> Kinney, Michael = D <michael.d.kinney@intel.= com>
> > > > > > > > > > >> Cc: lichao <<= a href=3D"mailto:lichao@loongson.cn">lichao@loongson.cn>; Kirkendall= , Garrett
> > > > > > > > > > >> <Garrett.Kirkendall@amd.com>; Grime= s, Paul
> > > > > > > > > > >> <Paul.Grimes@amd.com>; He, Jiangang
> > > > > <Jiangan= g.He@amd.com>;
> > > > > > > Leif
> > > > > > > > > > >> Lindholm <quic_llindhol@quicinc.com>= ; Andrew Fish
> > > > > > > > > > >> <afish@apple.com>
> > > > > > > > > > >> Subject: RE: [ed= k2-devel] The principles of EDK2
> > > > > > > > > > >> module reconstru= ction for archs
> > > > > > > > > > >>
> > > > > > > > > > >> [AMD Official Us= e Only - General]
> > > > > > > > > > >>
> > > > > > > > > > >> Thanks Ray, here= are my responses.
> > > > > > > > > > >> https://nam11.safelinks.protection.outlook.com/?url=3Dh
> > > > > > > > > > >> tt
> > > > > > > > > > >> ps%3
> > > > > > > > > > >> A%2F
> > > > > > > > > > >> %2Fg
> > > > > > > > > > >> ithub.com%2Ftian= ocore-docs%2Fedk2-
> > > > > > > CCodingStandardsSpecification
> > > > > > > > > > >> %2Fp
> > > > > > > > > > >>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> ull%2F2&amp;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&amp;sdata > > > > > > > =3D
> > > > > > > > > HAq
> > > > > > > > > > >>
> > > > > > >
> > > > >
> > ou4JyY1yxDthuQ1dEKcF7Q3o4W77Oo9rOOvkXNWU%3D&amp;reserved=3D0<= br> > > > > > > > > > > >>
> > > > > > > > > > >> @Kinney, Michael= D we may also need your
> > > > > > > > > > >> clarification on= the
> > > > > > > comments.
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >>> -----Origina= l Message-----
> > > > > > > > > > >>> From: Ni, Ra= y <ray.ni@intel.com>
> > > > > > > > > > >>> Sent: Thursd= ay, September 29, 2022 3:42 PM
> > > > > > > > > > >>> To: Attar, A= bdulLateef (Abdul Lateef)
> > > > > > > > > > >>> <AbdulLateef.Attar@amd.com>; Ch= ang, Abner
> > > > > > > > > > >>> <Abner.Chang@amd.com>; Sunil V L
> > > > > > > > > > >>> <sunilvl@ventanamicro.com>; devel@edk2.groups.io
> > > > > > > > > > >>> Cc: Kinney, = Michael D <michael.d.kinne= y@intel.com>;
> > > > > > > > > > >>> lichao <<= a href=3D"mailto:lichao@loongson.cn">lichao@loongson.cn>; Kirkendall= , Garrett
> > > > > > > > > > >>> <Garrett.Kirkendall@amd.com>; = Grimes, Paul
> > > > > > > > > > >>> <Paul.Grimes@amd.com>; He, Jiangang > > > > > <Jiangan= g.He@amd.com>;
> > > > > > > > > > >>> Leif Lindhol= m <quic_llindhol@quicinc.co= m>; Andrew
> > > > > > > > > > >>> Fish <afish@apple.com>
> > > > > > > > > > >>> Subject: RE:= [edk2-devel] The principles of EDK2
> > > > > > > > > > >>> module recon= struction for archs
> > > > > > > > > > >>>
> > > > > > > > > > >>> Caution: Thi= s message originated from an External
> Source.
> > > > > > > > > > >>> Use proper c= aution when opening attachments,
> > > > > > > > > > >>> clicking lin= ks, or
> > > > > > > responding.
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>> Abner,
> > > > > > > > > > >>> Comments in<= br> > > > > > > > > > > >>> https://nam11.safelinks.protection.outlook.com/?url=3D
> > > > > > > > > > >>> ht
> > > > > > > > > > >>> tps%
> > > > > > > > > > >>> 3A%2
> > > > > > > > > > >>> F%2F
> > > > > > > > > > >>> gith
> > > > > > > > > > >>> ub.com%2Ftia= nocore-docs%2Fedk2-
> > > > > > > > > > >>>
> CCodingStandardsSpecification%2Fpull%2F2%23pullreque
> > > > > > > > > > >>> st
> > > > > > > > > > >>> revi
> > > > > > > > > > >>> ew-
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 1124763311&amp;data=3D05%7C01%7CAbner.Chang%40amd.com%7Cd825e24 > > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 8625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82d994e183d%7C0
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> > %7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%<= br> > > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> >
> 7C%7C%7C&amp;sdata=3DRXxgpbEr6ivbqP1R6%2B3Rxl%2ByJAnaUJuaYYKdfCH > > > > > > > > > > >>> 8jo8%3D&= amp;reserved=3D0
> > > > > > > > > > >>>
> > > > > > > > > > >>> We can discu= ss more in tomorrow's meeting.
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>>> -----Ori= ginal Message-----
> > > > > > > > > > >>>> From: At= tar, AbdulLateef (Abdul Lateef)
> > > > > > > > > > >>>> <AbdulLateef.Attar@amd.com><= br> > > > > > > > > > > >>>> Sent: Th= ursday, September 29, 2022 3:11 PM
> > > > > > > > > > >>>> To: Chan= g, Abner <Abner.Chang@amd.com= >; Sunil V L
> > > > > > > > > > >>>> <sunilvl@ventanamicro.com>; devel@edk2.groups.io;
> > > > > > > > > > >>>> Ni, Ray = <ray.ni@intel.com>
> > > > > > > > > > >>>> Cc: Kinn= ey, Michael D <michael.d.k= inney@intel.com>;
> > > > > > > > > > >>>> lichao &= lt;lichao@loongson.cn>; Kirken= dall, Garrett
> > > > > > > > > > >>>> <Garrett.Kirkendall@amd.com>= ;; Grimes, Paul
> > > > > > > > > > >>>> <Paul.Grimes@amd.com>;
> > > > > > > > > > >>> He,
> > > > > > > > > > >>>> Jiangang= <Jiangang.He@amd.com>; Le= if Lindholm
> > > > > > > > > > >>>> <quic_llindhol@quicinc.com>;= Andrew Fish
> > > > > > > > > > >>>> <afish@apple.com>
> > > > > > > > > > >>>> Subject:= RE: [edk2-devel] The principles of EDK2
> > > > > > > > > > >>>> module r= econstruction for archs
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Hi Abner= ,
> > > > > > > > > > >>>> &nb= sp;    Looks good to me.
> > > > > > > > > > >>>> Reviewed= -by:  Abdul Lateef Attar <abdat= tar@amd.com>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Thanks > > > > > > > > > > >>>> AbduL > > > > > > > > > > >>>>
> > > > > > > > > > >>>> -----Ori= ginal Message-----
> > > > > > > > > > >>>> From: Ch= ang, Abner <Abner.Chang@amd.com>
> > > > > > > > > > >>>> Sent: 28= September 2022 20:31
> > > > > > > > > > >>>> To: Suni= l V L <sunilvl@ventanamicro.= com>;
> > > > > > > > > > >>>> devel@edk2.groups.io; ray.ni@intel.com
> > > > > > > > > > >>>> Cc: Kinn= ey, Michael D <michael.d.k= inney@intel.com>;
> > > > > > > > > > >>>> lichao &= lt;lichao@loongson.cn>; Kirken= dall, Garrett
> > > > > > > > > > >>>> <Garrett.Kirkendall@amd.com>= ;; Grimes, Paul
> > > > > > > > > > >>>> <Paul.Grimes@amd.com>;
> > > > > > > > > > >>> He,
> > > > > > > > > > >>>> Jiangang= <Jiangang.He@amd.com>; At= tar, AbdulLateef
> > > > > > > > > > >>>> (Abdul > > > > > > > > > > >>>> Lateef) = <AbdulLateef.Attar@amd.com<= /a>>; Leif Lindholm
> > > > > > > > > > >>>> <quic_llindhol@quicinc.com>;= Andrew Fish
> > > > > > > > > > >>>> <afish@apple.com>
> > > > > > > > > > >>>> Subject:= RE: [edk2-devel] The principles of EDK2
> > > > > > > > > > >>>> module r= econstruction for archs
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> [AMD Off= icial Use Only - General]
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> I just h= ad created PR to update edkII C coding
> > > > > > > > > > >>>> standard= spec for the file and directory naming. We
> > > > > > > > > > >>>> can revi= ew 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=3D
> > > > > > > > > > >>> ht
> > > > > > > > > > >>> tps%
> > > > > > > > > > >>> 3A%2
> > > > > > > > > > >>> F%2F
> > > > > > > > > > >>> gith
> > > > > > > > > > >>>> ub.com%2= Ftianocore-docs%2Fedk2-
> > > > > > > > > > >>> &amp;dat= a=3D05%7C01%7CAbner.Chang%40amd.c
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> om%7Cd825e248625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82
> > > > > > > > > > >>> d994e18
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 3d%7C0%7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJ
> > > > > > > > > > >>> WIjoiMC4wLj<= br> > > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C% > > > > > > > > > > >>> 7C%7C&a<= br> > > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> mp;sdata=3DX4z9puj81nIGTqtMxC9igDZyBPOT6OTWSU%2BjoIowo%2BE%3D&a > > > > > > > > > > >>> mp;reserv > > > > > > > > > > >>>> ed=3D0 > > > > > > > > > > >>>> CCodingS= tandardsSpecification/pull/2
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> The nami= ng rule is mainly for the new module or new
> file
> > IMO.
> > > > > > > > > > >>>> Some exi= sting module may not meet the guidelines
> > > > > > > > > > >>>> mentione= d in this
> > > > > > > > > spec.
> > > > > > > > > > >>>> Thus we = need the principles of EDK2 module
> > > > > > > > > > >>>> reconstr= uction on the existing module to support
> > > > > > > > > > >>>> other pr= ocessor archs and not impacting the
> > > > > > > > > > >>> existing pla= tforms (e.g.
> > > > > > > > > > >>>> rename t= he INF file or directory to meet the
> guidelines).
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Sunil, s= eems RISC-V CpuDxe meet the guideline.
> > > > > > > > > > >>>> Please c= heck
> > > > > it.
> > > > > > > > > > >>>> Just fee= l that having  CpuDxe.c to Riscv64 folder
> > > > > > > > > > >>>> is not q= uite a best solution. I think at least we
> > > > > > > > > > >>>> can abst= ract the protocol structure and protocol
> > > > > > > > > > >>>> installa= tion under CpuDxe\ and have the arch
> > > > > > > > > > >>>> implemen= tation under arch folder. We can discuss
> > > > > > > > > > >>>> this lat= er after we confirming the
> > > > > > > > > > >>> guideline an= d principles.
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Thanks > > > > > > > > > > >>>> Abner > > > > > > > > > > >>>>
> > > > > > > > > > >>>>> ----= -Original Message-----
> > > > > > > > > > >>>>> From= : Sunil V L <sunilvl@ventana= micro.com>
> > > > > > > > > > >>>>> Sent= : Wednesday, September 28, 2022 3:34 PM
> > > > > > > > > > >>>>> To: = devel@edk2.groups.io; ray.ni@intel.com
> > > > > > > > > > >>>>> Cc: = Chang, Abner <Abner.Chang@amd.com= >; Kinney,
> > > > > Michael
> > > > > > > > > > >>>>> D &l= t;michael.d.kinney@intel.com<= /a>>; lichao
> > > > > > > > > > >>>>> <= lichao@loongson.cn>; Kirkendal= l, Garrett
> > > > > > > > > > >>>>> <= Garrett.Kirkendall@amd.com>; Grimes, Paul
> > > > > > > > > > >>>>> <= Paul.Grimes@amd.com>; He, Jia= ngang
> > > > > > > > > > >>>>> <= Jiangang.He@amd.com>; Attar, = AbdulLateef (Abdul
> > > > > > > > > > >>>>> Late= ef) <AbdulLateef.Attar@amd.= com>; Leif
> Lindholm
> > > > > > > > > > >>>>> <= quic_llindhol@quicinc.com&= gt;; Andrew Fish
> > > > > > > > > > >>>>> <= afish@apple.com>
> > > > > > > > > > >>>>> Subj= ect: Re: [edk2-devel] The principles of EDK2
> > > > > > > > > > >>>>> modu= le reconstruction for archs
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> Caut= ion: This message originated from an External
> > Source.
> > > > > > > > > > >>>>> Use = proper caution when opening attachments,
> > > > > > > > > > >>>>> clic= king links, or
> > > > > > > responding.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> On W= ed, Sep 28, 2022 at 03:33:45AM +0000, Ni, Ray
> > wrote:
> > > > > > > > > > >>>>> Hi R= ay,
> > > > > > > > > > >>>>>><= br> > > > > > > > > > > >>>>>>&= nbsp;   1.  When a new arch's implementation is
> > > > > > > > > > >>>>>> = introduced to the existing
> > > > > > > > > > >>>>> modu= le which was developed for the specific arch:
> > > > > > > > > > >>>>>><= br> > > > > > > > > > > >>>>>>&= nbsp;   1.  The folder reconstruction:
> > > > > > > > > > >>>>>><= br> > > > > > > > > > > >>>>>>&= nbsp;   *   Create arch folder for the existing arch > > implementation
> > > > > > > > > > >>>>>> = [Ray] Do you move existing arch implementation to
> > > > > > > > > > >>>>>> = that arch
> > > > > > > folder?
> > > > > > > > > > >>>>>> = It will
> > > > > > > > > > >>>>> brea= k existing platforms a lot.
> > > > > > > > > > >>>>>><= br> > > > > > > > > > > >>>>>>&= nbsp;   *   Create the arch folder for the new introduc= ed
> > arch
> > > > > > > > > > >>>>>> = [Ray] I agree. But if we don't create arch folder
> > > > > > > > > > >>>>>> = for existing arch
> > > > > > > > > > >>>>> impl= ementation, the pkg layout will be a mess.
> > > > > > > > > > >>>>>><= br> > > > > > > > > > > >>>>>> = [Ray] Hard for me to understand all the principles
> here.
> > > > > > > > > > >>>>>> = Maybe we review
> > > > > > > > > > >>>>> exis= ting code including to-be-upstreamed code and
> > > > > > > > > > >>>>> deci= de how
> > > > > > > to go.
> > > > > > > > > > >>>>>><= br> > > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> Coul= d you please take a look below changes which
> > > > > > > > > > >>>>> is t= rying to add RISC-V support for CpuDxe?
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>> https://nam11.safelinks.protection.outlook.com/?url=3D
> > > > > > > > > > >>> ht
> > > > > > > > > > >>> tps%
> > > > > > > > > > >>> 3A%2
> > > > > > > > > > >>> F%2F
> > > > > > > > > > >>> gith
> > > > > > > > > > >>>>> ub.c= om%2Ftianocore%2Fedk2-
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> staging%2Fcommit%2Fbba1a11be47dd091734e185afbed73ea75708749&amp; > > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> data=3D05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08d
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> aa123e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 2732494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sd > > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> >
> ata=3DVq6pJLnn8yJrJhFZn7LfLbZzrtpG4n1VLWgAil6J38U%3D&amp;reserved= =3D0
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>> https://nam11.safelinks.protection.outlook.com/?url=3D
> > > > > > > > > > >>> ht
> > > > > > > > > > >>> tps%
> > > > > > > > > > >>> 3A%2
> > > > > > > > > > >>> F%2F
> > > > > > > > > > >>> gith
> > > > > > > > > > >>>>> ub.c= om%2Ftianocore%2Fedk2-
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> staging%2Fcommit%2F7fccf92a97a6d0618a20f10622220e78b3687906&amp;da=
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> ta=3D05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08daa1
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 23e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947273
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 2494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata > > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> >
> =3DxFmvUv58vh4AUAM17Qy9G5jZWFZlK2Ozt3njpG1e8%2BY%3D&amp;reserv
> > > > > > > > > > >>>>> ed= =3D0
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> What= do you suggest with above example?
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> 1) C= ommon INF for all architectures - but modify
> > > > > > > > > > >>>>> INF = alone, no
> > > > > > > > > > >>>>> X86 = folder creation.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> This= is what I have done in the commit above. May
> > > > > > > > > > >>>>> be o= f least impact to existing code since it is only INF
> > change.
> > > > > > > > > > >>>>> But = like you mentioned this is bit weird that X86
> > > > > > > > > > >>>>> file= s will remain in root folder directly along
> > > > > > > > > > >>>>> with= some common
> > > > > files.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> 2) C= ommon INF (CpuDxe.inf) + create arch folders
> > > > > > > > > > >>>>> X86,= X64, IA32,
> > > > > > > > > > >>>>> Risc= V64 etc
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> IMO,= this is probably the best approach. What
> > > > > > > > > > >>>>> woul= d be the challenges with this?
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> 3) S= eparate INF for arch like CpuDxe.inf for x86,
> > > > > > > > > > >>>>> CpuD= xeRiscV64.inf for
> > > > > > > > > > >>>> RISC-V.<= br> > > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> This= again probably is not a good idea.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> 4) I= f the module/library is specific to one arch (ex:
> > > > > > > > > > >>>>> SMM(= X86), SBI(RISC-V)), then create separate INF.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> Than= ks!
> > > > > > > > > > >>>>> Suni= l
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >

--_000_MN2PR12MB3966302441AEEFB0F28737BAEA229MN2PR12MB3966namp_--