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.49]) by mx.groups.io with SMTP id smtpd.web08.8999.1663947528545415409 for ; Fri, 23 Sep 2022 08:38:48 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@amd.com header.s=selector1 header.b=LDZ2jghj; 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.49, mailfrom: abner.chang@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WhF0mbaN8k35XwdP/0WrLPWZIN4Mn8B2wWxZgFDLQBWI+ZkEt4QyaW1ZdGo6UwWgF7idvQUeZhnoocp8o7IVVt4BhCYOD/ksLlssuJMeCvSZV5ccCw+09TzPXV0YO+GN/CtXdp0v/l1uttW7j6C8vEodGtpgIWZ+RKjSKkvRsE10uvp4gFS9aOP8o6ASlsYqutqDjkxg1sFR+n5cFg8zX2aVOTAwj1NTprjt/tSDlLvFRzCGKOGD6q7o6DEgrlL6lGfgWCyMCNBoLpqHwKaePzZW510B2JXYrf74ZH4nRciw+z8uM7/PLps7ZOOD38zZkJZNAePgx/rA9p/GCejKWw== 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=/UOsj5Mn0Cd/ij1bmYlzZfUy4RJmpPiC6dsjzi+Mqgk=; b=NDM3ZSIJPvPJIks9y/SecWquQYrEAltWDRy2D6MBpPsg+/1AKlJ0Iua6oA2L4ZiGhwoTnA91+xPiDdLZOVkKLFpEVGMEWrMLVUAxjvAr1P4wustvU7eTxsGAg4neoF5Tks8lo/8hGgdDVUCGPrqk4cuEX9Ax5Bu/T4BDxwKG7QBssgIWrx6r7JgRcbAJKZfJZyi7YWsTAvZijGYQhnwuKnJYfhvDf3h6WK69amoVaO7UKTMzWX1/PL5EraEJGgFyA7pYB1GYNNviUroQ2kdMYr5jinvj30w/qFKjjEEz00mgT6dT35X24o0NN618OcxFcSXUIxEYheDyZRX/tzF4+Q== 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=/UOsj5Mn0Cd/ij1bmYlzZfUy4RJmpPiC6dsjzi+Mqgk=; b=LDZ2jghj+jzddHxqiZY0rkyCDtBX2bddP+Jzbp8jQ59FRMnAKwqVAGkTeisVdTuKnKQ03G2+pddeFntGaPlbIUkqfqZMS2sj83zx4H0/4JpFqL096ALHbMxFvWAqfNGO3pEAJ8GFz+JT+DyiYbghvqbjUr0suPwp1V7oC7SPrzA= Received: from MN2PR12MB3966.namprd12.prod.outlook.com (2603:10b6:208:165::18) by PH8PR12MB7133.namprd12.prod.outlook.com (2603:10b6:510:22e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.18; Fri, 23 Sep 2022 15:38:44 +0000 Received: from MN2PR12MB3966.namprd12.prod.outlook.com ([fe80::998b:f1a2:b183:43be]) by MN2PR12MB3966.namprd12.prod.outlook.com ([fe80::998b:f1a2:b183:43be%4]) with mapi id 15.20.5654.020; Fri, 23 Sep 2022 15:38:44 +0000 From: "Chang, Abner" To: "devel@edk2.groups.io" CC: Ray Ni , "michael.d.kinney@intel.com" , Sunil V L , lichao , "Kirkendall, Garrett" , "Grimes, Paul" , "He, Jiangang" , "Attar, AbdulLateef (Abdul Lateef)" , Leif Lindholm , Andrew Fish Subject: The principles of EDK2 module reconstruction for archs Thread-Topic: The principles of EDK2 module reconstruction for archs Thread-Index: AdjPX4ZZG0rDXS4WTdOIWvoiYOLYcg== Date: Fri, 23 Sep 2022 15:38:43 +0000 Message-ID: Accept-Language: zh-CN, en-US X-Mentions: ray.ni@intel.com,michael.d.kinney@intel.com 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-09-23T15:38:40Z; 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=1adf4523-dad4-4e69-b799-209a99558519; 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_|PH8PR12MB7133:EE_ x-ms-office365-filtering-correlation-id: 00d9bf1e-da9d-455b-0b09-08da9d79b2a5 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0yb2TXZlR2wSIFvssxVSSHHIpnRHWKx5L1UbRAJsW38RFGlC+/fZY8oinmcgCRjxzk/gUTEwR4QgmjTp59kYQvlMzZDWBD89pbzJJzkk/o/KDgbHfNTKNIY2pHRQmnNxU+KPxMpQ3BWHzKkEND5r3lYYFY0/JG1EGoo+1PNX4XYVyuIUvhHo5EJBl08JR/qN//e/O1mKqJi3cxOuxAWfqjFx918yQ9FiMqlSFMUzuQ4Legs/SHY7LPWHhTivrzCVx8bhdn7w0KYiw1uEo6YSW4E/V2ahGLySbQPXMJvw/ytH3qFq5UQI2WEGP6d0XDX1FhVuLxABe0U5zx5h1MZJK1GNF5ljhLyZ9vGmxWny5sC6ZyV8043u18FkG2o2xwzpUH2itScTKacrmeoDEEOxoBCHn5tKj6Hmz1QGQ/HQGvY0ZbMnr7nFHKJEhK8v5r+48YhHNKU7F26vI937BpstyLDaRMgwJkOA+nyYPZf+s16gI3sCUvbJtRsL/04S1EhX9FZwLJ6QJU4cZbNhXvffpI82qmtReFWvNNvd+WfWRWA4giS6eZ3/dxf5T6WVwXCmoJfSfYxhj/rOYNdg6J0CUh8iG7HALcwHOus68WVaolukWomCUzM0cW1SLnp/3QYUtxZYhgLEbyZH6rm2YrF+3DKnmdpF+KS332G/43BLFUIguIyhMlDupAPP6K/2iEziRJwGj8yxYNF8cZIVM3lI4bQ/YfDF4yxrwm3Sg1ZtZuPbGgb5HZgBrhxp0Tql1baAi0Ne+p6axNiL0clbu9wo/wbI/YuFqO3jDyq6ayI2xmM= 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)(346002)(376002)(396003)(366004)(39860400002)(136003)(451199015)(6916009)(122000001)(38100700002)(66476007)(55016003)(4326008)(41300700001)(76116006)(33656002)(8676002)(186003)(66556008)(66946007)(54906003)(316002)(64756008)(83380400001)(66446008)(43170500006)(66574015)(6506007)(52536014)(7696005)(9686003)(86362001)(26005)(2906002)(5660300002)(38070700005)(8936002)(71200400001)(478600001);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?G6ATdaGMYDNdt5/kYLuD1ok1tc6JSJxpYXtNkBhBXHhsJnQyU53zrjK0xN8a?= =?us-ascii?Q?SDxSoJRUHFHn6I90jk47pd7KGjTffITKAwkzarKRm3NnUMaymBRD4Z++Ka00?= =?us-ascii?Q?xMfXvLIaS/RUquZuSu+LNezSHFlTb/1L6vf9d98okfln/G69/xEPkYQ+Hywh?= =?us-ascii?Q?JPqF6WytX7wVoc2mABXHMoMOqkfJDx9EUOVpTkY0M1VTGkSMgDHc0GL3gNmr?= =?us-ascii?Q?RDfZj6PU/07Xl2MfFyQU4cVBsibFlWIXTRNdH/B1BWS7xSsoadEy7VzDZmu6?= =?us-ascii?Q?9PTdxvYTj7fGr+Enns1oXDA+oNMGj2uuQr5RH2oextKfX/eLNvgJ59fnbsm9?= =?us-ascii?Q?Y4Gwy5DWzSZpYGq4mvPlnYGiYSqUTCiuGAwodS/Ozx8M67XiYodg+tE+YTq0?= =?us-ascii?Q?r6kXyouE9TWEu7kli7mND5y2u1bQ9kqsBLiE9bIIsfKZsjLdk9cUXcLp6P/E?= =?us-ascii?Q?28HDHYlXvI/rd7CedzPlt2EQf3LjhccnGqCB2SS3pTIl3L8LLfVI3/fVOwNr?= =?us-ascii?Q?kmW6+ND388d6ZrobEJoJWyFQjacH4TO5qMgOjX2htZuB3L6UMrWrsaEuVGX3?= =?us-ascii?Q?AkHPJh7Xr+QXWtK6hy9jhfmr28aEG4kzPubXcEmyQbiGr51e/m1w4KVf4mtp?= =?us-ascii?Q?Y+ysKGOpDWXyDuW4OP0DcUeCnuwPdoKPJ31aZyXkSY0Z0oX3gDUKrLADHeyG?= =?us-ascii?Q?qMSYFzonUsdk3IxHgLeJ9jXI1KjLIqyKZVp0er/prUMwwe32PKqZe89g6mI2?= =?us-ascii?Q?bIOr9SwfJCUDsQeEa62CO+k4XLMuCsVlU8rvwj4XFALrNhy3XRNskaC0xwj1?= =?us-ascii?Q?8wtr1tX9tIbtw3xXmRpXw3lKgr/DSom5CeK+/QjYelOZ833stFnjja4GMA0v?= =?us-ascii?Q?WbKMYRl2VokIDagbs5jkj36iJvZl5R4wQj94+6KDTLnYjVWts1dusT6kggxE?= =?us-ascii?Q?ASY/8xpqlfzFGBt2u1ErdXAvcSyqEfKhrUu3qHjWN6FzsAQ4wjVfwZrhPXLU?= =?us-ascii?Q?GVfEi9TDg1Eb8+go3+PfzVDKfN05FQrfshNftrtvRIXAg4VJpTmYn1qJw702?= =?us-ascii?Q?It6wVRmpR3g4AlKJSlomazFVjT+kYwQLJk5qHp7th75/W58FCi/axUGWZ0+j?= =?us-ascii?Q?4FDgHzhW/3xcp5SbFuDqQtQjtPn+kCGAN0bBo5eMGpywlFOONnUlRROz9aju?= =?us-ascii?Q?9oDbej+NdvRJG+6cGBcSkgQtoRcUKvn5m6idTG2Ti12lbvzin289aPfbj6hy?= =?us-ascii?Q?pRIGLgaZ4T5Z2UAmHMR425fD28WA8vG2WBvYJyP1pQmkZpnFlZiHGHkrVieM?= =?us-ascii?Q?k6UPhi+5He6UlALu2T5dqBmSPyTPIHCu4yTonj+gGtWJNj/tuaNSMmbl6ew+?= =?us-ascii?Q?FOEl4imQPvy6UUc4UodZ6CGRCzpZs3DlIlz9OvCThbI5ovaunrcTtmXCyAIz?= =?us-ascii?Q?GTBEXSs8QbsQoMi4CjmESTd+bVsOhkq0wztKqxpuH/EUCJ0nn7roI9vdg4Rf?= =?us-ascii?Q?ghkObcaTxtnT80q1K2pgb2IULl8ev87AYRraNPDh73Z00nMS1Yt7bVZF5LsT?= =?us-ascii?Q?A+TTSgOfmhuaEsamZ/6Sy/OshvsAmBIN472s/VeI?= 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: 00d9bf1e-da9d-455b-0b09-08da9d79b2a5 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2022 15:38:43.9485 (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: XeU/A9oYI87x1i+hpmaFfanT3PCf6mIIhP19/z95Alg1Y0vdmy414Xm61btPIfB65nFbysIWqBz8iIfBB1BszA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7133 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_MN2PR12MB3966EB27023F893CDB783AB2EA519MN2PR12MB3966namp_" --_000_MN2PR12MB3966EB27023F893CDB783AB2EA519MN2PR12MB3966namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [AMD Official Use Only - General] All, Today in edk2 open design meeting, we went through the draft of principles = of the EDK2 module reconstruction for accommodating different archs (IA32, = X64, Arm, AArch64, RiscV64, Loongson64 and etc.) or different vendors of th= e same arch (AMD/Intel to IA32 and X64). @Ray Ni and @michael.d.kinney@intel.com 1. We may need somewhere on edk2 repo or another place that can have PR = for the easy review, please let me know where I can create the PR instead o= f reviewing this through dev mailing list. 2. I didn't mention using CPUID, Family ID or PCD to have the different = code path for AMD and Intel. The reason is, * This decreases the readability of code. * That makes a confusing to the review process i. Says the maintai= ner/reviewer owns the package, however the patch is specific to AMD impleme= ntation but the change is in the file that mixes up Intel and AMD code. The= n who is supposed the right person to give the reviewed-by? Perhaps the AMD= edk2 module maintainers or reviewers is the proper person to give the revi= ewed-by for this case. Of course, other maintainers still can join the revi= ew process and give the comments. So to separate the arch-specific code in = a arch-specific source file simplifies the review, even that is just a smal= l delta between two implementations. ii. We can have the = maintainers or reviewers for the entire module or *Amd* files only. So the = maintainers/reviewers do not have to review the changes that only made for = other archs. But they have to help reviewing the common code if that gets i= mpact. 1. I didn't mention to have for the new module. = I prefer we just inherit the original module name or file name so we can kn= ow the module or the source file has the different implementation for archs= in the file browser (when the files are sorted in alphabet). Lets discuss this using PR if possible. Thanks Abner Below is the draft of principles: Preface: The principle is mainly for UefiCpuPKg, but the same principle maybe applie= d to the EDK2 module that has the processor architecture dependence (such a= s the BaseLib under MdePkg/Library). Most of the EDK2 modules under UefiCpu= Pkg were developed specifically to IA32/X64 architecture, that is necessary= to reconstruct the folder or revise the source files to accommodate other = processor architectures. The EDK2 module reconstruction is also required fo= r accommodating the same-arch-but-different-vendor's implementation (e.g., = Intel and AMD for the X86 based processors). The EDK2 module may be strictl= y developed based on the specific processor architecture. The new introduce= d implementation for other processor architectures may consider to have a s= eparate EDK2 module instance. Not all of the EDK2 modules revising can exac= tly meet the principles listed below, that depends on the delta between the= original EDK2 module and the implementation for the new introduced process= or architecture. It may require the further discussions with EDK2 module ma= intainers. The [Arch] refers to the Processor Architecture. The [Module] refer to the EDK2 module. The [X86] refers to both IA32 and X64. The principles to create the X86 folder in the module: 1. When X86-vendor's implementation is introduced to the existing module= : 1. The folder reconstruction: A-1. If the module is obviously used by IA32/X64 only * No need to create X86 folder * Create X86-vendor's stuff under the root directory of module A-2. If the existing module is expected to accommodate the different archs = or the module already has multiple archs: * Create X86 folder * Create X86-vendor's stuff under X86 folder 1. The files reconstruction: B-1. The module INF metafile * The existing INF metafile should be kept without relocation. Should n= ot have the impacts to the existing DSC/FDF file. * The new introduced INF metafile should be located under the root dire= ctory of module with the file naming format as below. This keeps the consis= tent module file structure. * .inf B-2. Source files The new arch implementation is introduced to = the module in order to leverage the source code and the module design archi= tecture, so * That is contributor's responsibility to review the source code and st= rip the arch-dependent code away and put it into the arch-specific file. Le= ave the common code in the original file if there is no arch-specific and a= rch-specific-feature wordings in the file name. Create a common file for th= e common implementation otherwise. * The file naming for the arch-specific file .* * The file naming for the common implementation < OriginalFileNaming >Common.* * That is contributor's responsibility to relocate the arch-specific so= urce files to the arch-specific folder. * That is contributor's responsibility to make sure the original INF me= tafile can properly pull-in the source file from arch-specific folder after= the source file reconstruction. * The common source files should be located under the root directory of= module 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 * Create the arch folder for the new introduced arch 1. The files reconstruction: B-1. The module INF metafile * The existing INF file should be kept without the relocation. Should n= ot have the impacts to the existing DSC/FDF file. * The new introduced INF metafile should be located under the root dire= ctory of module with the file naming format as below. This keeps the consis= tent module file structure. * < OriginalFileNaming>.inf B-2. Source files The new arch implementation is introduced to t= his module in order to leverage the source code and the module design archi= tecture, so * That is contributor's responsibility to review the source code and st= rip the arch-dependent code away and put it into the arch-specific file. Le= ave the common code in the original file if there is no arch-specific wordi= ng in the file name. Create a common file for the common implementation oth= erwise. * The file naming for the arch-specific source file < OriginalFileNaming >.* * The file naming for the common implementation Common.* * That is contributor's responsibility to relocate the arch-specific so= urce files to the arch-specific folder. * That is contributor's responsibility to make sure the original INF me= tafile can properly pull-in the source file from arch-specific folder after= the source file reconstruction. * The common source files should be located under the root directory of= module 1. When a new arch implementation has a huge delta with the original imp= lementation Create a separate module instance. The naming of the module should follow b= elow format, * Add the arch prefix with the original module name: < OriginalModuleNaming> --_000_MN2PR12MB3966EB27023F893CDB783AB2EA519MN2PR12MB3966namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[AMD Official Use O= nly - General]


All,

Today in edk2 open design meeting, we went through t= he draft of principles of the EDK2 module reconstruction for accommodating = different archs (IA32, X64, Arm, AArch64, RiscV64, Loongson64 and etc.) or = different vendors of the same arch (AMD/Intel to IA32 and X64).

 

@Ray Ni and @michael.d.kinney@intel.com

  1. We may need somewhere on edk2 repo or another place that can have PR = for the easy review, please let me know where I can create the PR instead o= f reviewing this through dev mailing list.
  2. I didn’t mention using CPUID, Family ID o= r PCD to have the different code path for AMD and Intel. The reason is,
    1. This decreases the readability of code.
    2. That mak= es a confusing to the review process

       =             &nb= sp;            =             &nb= sp;       i.  = ;   Says the maintainer/reviewer owns the= package, however the patch is specific to AMD implementation but the chang= e is in the file that mixes up Intel and AMD code. Then who is supposed the right person to give the reviewed-by? Perhaps the AMD edk2 module main= tainers or reviewers is the proper person to give the reviewed-by for this = case. Of course, other maintainers still can join the review process and gi= ve the comments. So to separate the arch-specific code in a arch-specific source file simplifies the revie= w, even that is just a small delta between two implementations.<= /p>

       =             &nb= sp;            =             &nb= sp;      ii. &nbs= p;   We can have the maintainers or revie= wers for the entire module or *Amd* files only. So the maintainers/r= eviewers do not have to review the changes that only made for other archs. But they have to help reviewing the common code if that gets impact= .

  1. I didn’t mention to have <phase><arch><basename&= gt; for the new module. I prefer we just inherit the original module name o= r file name so we can know the module or the source file has the different implementation for archs in the file browser (when the files= are sorted in alphabet).

 

Lets discuss this using PR if possible.

Thanks

Abner

 

 

Below is the draft of principles:

 

Preface:

The principle is mainly for UefiCpuPKg, but the same= principle maybe applied to the EDK2 module that has the processor architec= ture dependence (such as the BaseLib under MdePkg/Library). Most of the EDK= 2 modules under UefiCpuPkg were developed specifically to IA32/X64 architecture, that is necessary to reconstruct th= e folder or revise the source files to accommodate other processor architec= tures. The EDK2 module reconstruction is also required for accommodating th= e same-arch-but-different-vendor’s implementation (e.g., Intel and AMD for the X86 based processors). The EDK= 2 module may be strictly developed based on the specific processor architec= ture. The new introduced implementation for other processor architectures m= ay consider to have a separate EDK2 module instance. Not all of the EDK2 modules revising can exactly meet the= principles listed below, that depends on the delta between the original ED= K2 module and the implementation for the new introduced processor architect= ure. It may require the further discussions with EDK2 module maintainers.

 

The [Arch] refers to the Processor Architecture.

The [Module] refer to the EDK2 module.

The [X86] refers to both IA32 and X64.

 

The principles to create the X86 folder in the mo= dule:

  1. When X86-vendor’s implementation is introduced to the existi= ng module:
  1. The folder reconstruction:

A-1.= If the module is obviously used by IA32/X64 only

  • No need to create X86 folder
  • Create X86-vend= or’s stuff under the root directory of module

A-2.= If the existing module is expected to accommodate the different archs or t= he module already has multiple archs:

  • Create X86 folder
  • Create X86-vendor’s<= b> stuff under X86 folder

 

  1. The files reconstruction:

B-1. The module INF m= etafile

  • The existing INF metafile should be kept without relocation. Should= not have the impacts to the existing DSC/FDF file.
  • = The new introduced INF metafile should be located under the root directory = of module with the file naming format as below. This keeps the consistent m= odule file structure.
    • <OriginalFileName><arch>.inf

 

        &= nbsp;           &nbs= p;B-2. Source files

        &= nbsp;           &nbs= p;         The new arch impleme= ntation is introduced to the module in order to leverage the source code an= d the module design architecture, so

  • That is contributor’s responsibility to review the source cod= e and strip the arch-dependent code away and put it into the arch-specific = file. Leave the common code in the original file if there is no arch-specific and arch-specific-feature wordings in th= e file name. Create a common file for the common implementation otherwise.<= b>
    • The file naming for the arch-specific file

<OriginalFile= Name ><arch>.*

    • The file naming for the common implementation

< OriginalFil= eNaming >Common.*

  • That is contributor’s responsibility to relocate the arch-spe= cific source files to the arch-specific folder.
  • That= is contributor’s responsibility to make sure the original INF metafi= le can properly pull-in the source file from arch-specific folder after the= source file reconstruction.
  • The common source files= should be located under the root directory of module

 <= /p>

  1. When a new arch’s implementation is introduced to the existi= ng module which was developed for the specific arch:
    1. The folder reconstruction:
    • Create arch folder for the existing arch implementation<= /li>
    • Create the arch folder for the new introduced arch

     

    1. The files reconstruction:

    B-1. The modul= e INF metafile

    • The existing INF file should be kept without the relocation. Should= not have the impacts to the existing DSC/FDF file.
    • = The new introduced INF metafile should be located under the root directory = of module with the file naming format as below. This keeps the consistent m= odule file structure.
      • < OriginalFileNaming><arch>.inf

     

    B-2. Source fi= les

            &nbs= p;            &= nbsp;       The new arch implementation is in= troduced to this module in order to leverage the source code and the module= design architecture, so

    • That is contributor’s responsibility to review the source cod= e and strip the arch-dependent code away and put it into the arch-specific = file. Leave the common code in the original file if there is no arch-specific wording in the file name. Create a commo= n file for the common implementation otherwise.
      • The file naming for the arch-specific source file

      < OriginalFil= eNaming ><arch>.*

        • The file naming for the common implementation

      <OriginalFile= Naming>Common.*

      • That is contributor’s responsibility to relocate the arch-spe= cific source files to the arch-specific folder.
      • That= is contributor’s responsibility to make sure the original INF metafi= le can properly pull-in the source file from arch-specific folder after the= source file reconstruction.
      • The common source files= should be located under the root directory of module

       

      1. When a new arch implementation has a huge delta with the original = implementation

      Create a separate module instance. The naming= of the module should follow below format,

      • Add the arch prefix with the original module name:
        • <= /ul>

        < OriginalMod= uleNaming><arch>

         

--_000_MN2PR12MB3966EB27023F893CDB783AB2EA519MN2PR12MB3966namp_--