From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mx.groups.io with SMTP id smtpd.web11.3839.1664336035831505196 for ; Tue, 27 Sep 2022 20:33:55 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="unable to parse pub key" header.i=@intel.com header.s=intel header.b=Kibkai+q; spf=pass (domain: intel.com, ip: 192.55.52.115, mailfrom: ray.ni@intel.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1664336035; x=1695872035; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7WwCz5gJxqRM7BWLn1KbzsQBcjfQp24UuSUxrxZCpTQ=; b=Kibkai+qi7hCl4f4jR2QfJ8zF9C0pDtpDVLp6+7NGOfzj98RjKOZKISx j5f3Kjb/YhCuygQWA/ybSSixn6YR486bp/6hvn+yN8m/mJx/AbU9+/Pwr P5Qu1n3WMVcA19sBef4gD/H63NeAzUp6yDGAYI8ArpJ/DZLRhT7fcypr4 eeiSIuz5wTE49rI0kDYxPyr/yjotVVWf1gldW0uPiOiVohwkU+IRyde8Q DKsMvkLLRoO0x/ae9EP2oEe2hRF/za60V9JGIX5NcbsNTXec5M+dpOQc2 JFAssfemUXvM8vW8yDlW2gt9jRFvIdv+0If8MDxZ+LRI0SOGgJ4xsfhVT g==; X-IronPort-AV: E=McAfee;i="6500,9779,10483"; a="301471224" X-IronPort-AV: E=Sophos;i="5.93,350,1654585200"; d="scan'208,217";a="301471224" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2022 20:33:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10483"; a="747275626" X-IronPort-AV: E=Sophos;i="5.93,351,1654585200"; d="scan'208,217";a="747275626" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by orsmga004.jf.intel.com with ESMTP; 27 Sep 2022 20:33:54 -0700 Received: from fmsmsx609.amr.corp.intel.com (10.18.126.89) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Tue, 27 Sep 2022 20:33:53 -0700 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by fmsmsx609.amr.corp.intel.com (10.18.126.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Tue, 27 Sep 2022 20:33:53 -0700 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx612.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31 via Frontend Transport; Tue, 27 Sep 2022 20:33:53 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.103) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.31; Tue, 27 Sep 2022 20:33:52 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e6q+UHaACeQZj+JH3DnKi1FHAODD471F8KESHmkpY2Xice4QP9A8w9Bx/FRtv1YzapvBRJeLEJa/xWFvU6EjhrVJPSBLZGI7CNfH9c3htnj3CUQEi8lLQ54bdQypzceHQ7v020bXsoXLhgy13pJHkxJv9ItgBn+zxqzJaIvF5Ppwz52cGSRW+/sqcaItBTltKx/oPtv41+Wga0EfdPQaUZKpZ5HU9iq8H8Z3s9E6cEqbvVnSAA4V/bAKo6KMHhvUEYBAIJwNay5tHdpRVmNQzSf08UuxDwd7q9dqsABtI7zU4xANqDy8MPpbt8vYeB6VquZedFZNTOot0AMKjJ/f1g== 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=hjTF5bTZDD9cnSIpqbPeverjbQ7GBiGWhM0hVNiljzM=; b=ToplNggd/myIbHm4Pje36e97o1uX3azZAqt8kAwundOT2Nshpfj9zlJ3W5v6DZcVFRWV6Lk5LZpcxXabvor18d6g/pMDRtgOuDEOUQJZPsXrORYvLiOu9HXLmUFyoaetwAVwZu029j7xNErPfyk4W5PgpDhp05Vdjca2U/TY574ddwuEzyfAEbJ5/74NVEfnDCFon2DQTTZhf6GKkHqIOnXRPSWH5lom8QE9OPcz9pObjigVpaHk2lRvcqK/Nx8AOjmqIwPyC2KABNOOCSzAXgjKdxVhy2H3USAVx+QuZio4BLyxGISCOCAQbfHoxnZqgfLRVXwjTmJlSRuDdTel0w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from MWHPR11MB1631.namprd11.prod.outlook.com (2603:10b6:301:10::10) by SJ1PR11MB6203.namprd11.prod.outlook.com (2603:10b6:a03:45a::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.25; Wed, 28 Sep 2022 03:33:45 +0000 Received: from MWHPR11MB1631.namprd11.prod.outlook.com ([fe80::483f:4bb5:a15f:f571]) by MWHPR11MB1631.namprd11.prod.outlook.com ([fe80::483f:4bb5:a15f:f571%11]) with mapi id 15.20.5676.017; Wed, 28 Sep 2022 03:33:45 +0000 From: "Ni, Ray" To: "devel@edk2.groups.io" , "abner.chang@amd.com" CC: "Kinney, Michael D" , Sunil V L , lichao , "Kirkendall, Garrett" , "Grimes, Paul" , "He, Jiangang" , "Attar, AbdulLateef (Abdul Lateef)" , Leif Lindholm , Andrew Fish Subject: Re: The principles of EDK2 module reconstruction for archs Thread-Topic: The principles of EDK2 module reconstruction for archs Thread-Index: AdjPX4ZZG0rDXS4WTdOIWvoiYOLYcgC9rttQ Date: Wed, 28 Sep 2022 03:33:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: 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-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=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MWHPR11MB1631:EE_|SJ1PR11MB6203:EE_ x-ms-office365-filtering-correlation-id: 70e0b3aa-0bd5-40cb-c37c-08daa1023f9b x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rrhd+misAI09u5k4J0CQ/S5ZEvap/YOtInlrw509Vt96hGJzhLPEgjYh85VDxlXaJPpGbr2ZZyqUQxOIczTp3zb8oXWAWwWUk3To3qmOcBktfcj+sefqB+66SmQtSdRnT4UWpwLmkE742mTO6e+alGzhZ+7VoVd/icDR/Vcmp9izamd+xNSVqraj61J3T5cmYlypg8s+39HwYZQOk2iIvlm7/v8hc2OsPYY5rOhsipQaOdCxZt2VhatbsLeOmtmjxcQHTXrl0VBKVzJ9rdKH5Xa+VGSOCyIAe7p7FbDPPHOB2smpxdYPIYb2JEPorcZFPALpkCcn+nNGEd0grGFzWBMo47w5+1C0tXL1vCyRw649NTiLLxFS92p/9ktpWJVrcD5mPCZB4s9psO2WGKGs6tfRTmaue07V1Uwl7lG8JQJCXPUySkFzEtR/Di//5Uayu82rIQqMeTLWGwf1NSBhVfbTywRklr406PVkVNHKIA1+tCIAxI1uTGVPHz6HZhMSsz+/x1Uzg2STQqMIctyL+u+oWB1NSBodGCGIueE/sX65OD6P93zzgMZIzHYTwgtzTigNvhszg+x8ysNllhIpduyJPOyXeUEngVvgx5taHi/fTSQbEfsw9d3ht/KbCQgMeRBhS4aZg+/3dYEnW0sFTOQNp6N+2S8fQ8UvotveZyIzHNmT0sbl00iKehAhpeZ/4qKasM0ytQeMnpl8XNhYzIjriykihcaWa8PWJHjxNghEUSOUc8Ac1LBHNp6LJWH6mcKkB3PI+Gf8Yl4RYsMBBf4zxMlO86IH4s5Qx9r1iWEBC4+vCTrl915fevAB7ocoOJA5n/qidTQp7T/4MVkqgA== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MWHPR11MB1631.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(346002)(39860400002)(396003)(136003)(376002)(366004)(451199015)(38100700002)(38070700005)(83380400001)(122000001)(82960400001)(66446008)(66556008)(66476007)(64756008)(8676002)(52536014)(26005)(4326008)(8936002)(7416002)(76116006)(66946007)(76236004)(6506007)(41300700001)(5660300002)(7696005)(86362001)(2906002)(55016003)(186003)(316002)(71200400001)(66899015)(9686003)(166002)(478600001)(33656002)(110136005)(54906003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?GIt1XXQ1TrgpYr1mLPfTbVgEhspXaeewYFYcfgnEdJo9OA5gDR5div9tF0hq?= =?us-ascii?Q?YeSzeTFIPex4fBj8go6Q0tyeL/AsTaxsKf/fXe9NiHtzuGX4LKQHjiAY2N0Q?= =?us-ascii?Q?mJaXhQPpXH86dFxoOxlhXl//aVO0bLIz1bPtVtDzwZgJm7tA8ZJaf+QTaPVr?= =?us-ascii?Q?LXDUmBJrStdaSjNYaO4VYEGnR3oBWug/2P4ssQRy77ZBWbTeMiNZCMKPZxC2?= =?us-ascii?Q?iTrjjQ967ZM+XtZASZzO+t+QqX9v+cfM8lKLsZ951Qsg1ypZLij1oVD3Ckml?= =?us-ascii?Q?BmZkLOyvzIUA7/zHrK5eo+LP7MYAbVnPEnjZeWTVoOI5Od3C4wW9+RaB5+92?= =?us-ascii?Q?2mQiVhX3v/f6ctlKcpSOW3amz7/NxKoQFYGGriHwSsEgIlLtHxKWrmDZW/oT?= =?us-ascii?Q?y3kasowkjTv1LH0Onv9P66GuaXMsg9eyAMsNcQ4TopXdxws8RE3A74YKplDH?= =?us-ascii?Q?g9avfUpnC1YDv5OfaOLwEpjVNagWDXm+n7zyqQSZnSXetMlB0dqNShqFTKVt?= =?us-ascii?Q?N8ObdNpmuYuGqLwPlQq0k0cmAxQpDQ/kHYyJX+MFTBDAkpmWSIN8GtLjKDQx?= =?us-ascii?Q?nPRArrUtdtmUnc17z0WxgYHpxNqbfGrbI9ffddcwizKEgW4mjL+TSxR0uQ47?= =?us-ascii?Q?a9S5RRa4m9cMR+L4czCFvshXkZGCwK0LXNB2gw3koQZsHtIEu4NI8ynDpXq5?= =?us-ascii?Q?LR6G7RVTanqzfFUZN3O0hYPDUClhkpnO8mw43Crif8HukwrVgUdpBXjmeUa5?= =?us-ascii?Q?+x+9w3H8mK0RHtRBbo5/h4xz1AwtzIJiIjEu5cX8nSgnU3znxuZFxhXhGSzr?= =?us-ascii?Q?qIJLy3wctkczSKKsQ5HwxlcgzQbJo0ARGz/f2g8gIUXWg04+uMPQPD2RA5wb?= =?us-ascii?Q?JraHsF2iM3V4S8nBzO7YgpSf93KQp6n2mYyGvDmTuL7effFCYTUkK9NO58if?= =?us-ascii?Q?XjgIeojxjmC5Mn6yrWrshWMpOq8tbtbsN/PqOyO5O33q2Wik0Sj8GSS9a5mi?= =?us-ascii?Q?q+Y/tqf2J7/nGwwjtc13gSM7nPuBBrdSPH95M8GD39jyjwlK3lIM2EieyhYL?= =?us-ascii?Q?3Yl0ZNf4OJeH2k9bc9fg91oQNd8Q+wVkgDNClekwsPmiPs38lvvyNVdvCVEY?= =?us-ascii?Q?TOrhnG5oU2wYZRViQn2b1wD0pR5o9v2AubYBRM1QYE5SKxl1VMoA7T7EVdhH?= =?us-ascii?Q?2iUzq3KE1YLPoyjK80unbmHpmw0fGPE7aeHu7mnUuhT458Wvk2yHZoskigYj?= =?us-ascii?Q?ejKn/LVDRyhe/s6La34jR3VyO1XbBw9JOpnNW7BpeR+mehr2TCER/d3IdPke?= =?us-ascii?Q?yz/nuYMWtlL0dWpFNIxWbMULM9tzft6JFjJKJBSm7U9+Vjsp9EIp12e+A6Xl?= =?us-ascii?Q?kWOiwipQlCxZphOE+edE+Zb8/poTEbWlGXnCShEwbNJHLdXNTpiq7Ed4L6Zv?= =?us-ascii?Q?zq3B3oTrnd0W4z9mazNgZ2ltObOxHjNY0c+uyToIISxRcrI3QOuMfF1HY2yR?= =?us-ascii?Q?EMGoti2kodwtS+GUT47bPr9TcfK16Pq3DOjDER8nP4WZJknUy1ilj644xxUf?= =?us-ascii?Q?XxLtlWbvth7TbJODQl0=3D?= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1631.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 70e0b3aa-0bd5-40cb-c37c-08daa1023f9b X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2022 03:33:45.5057 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7SiNuch1bCTJts2GQxZQFkIRr+k1runPfOQxCxDiApVYJrqaqUtw4LN1CeNUi9l0GyMlqM5Kkac4MqiYhoGq5w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR11MB6203 Return-Path: ray.ni@intel.com X-OriginatorOrg: intel.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_MWHPR11MB16319AA74D5CD0051CA8ED7E8C549MWHPR11MB1631namp_" --_000_MWHPR11MB16319AA74D5CD0051CA8ED7E8C549MWHPR11MB1631namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 [Ray] Looks good. 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 [Ray] "CpuDxe.inf" and "CpuDxeArm.inf"? is that your intention? New develo= pers may be confused that CpuDxe.inf supports only X86 arch. Do you have an example that one module supporting multiple archs using diff= erent INF files? MdeModulePkg/DxeIpl is a module supporting different archs= with the same INF file. Or shall we leave it to be decided between the patch contributor and packag= e/module maintainer? 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 [Ray] If you check the MpInitLib, most of SEV logic are moved to AmdSev.c. = But MpLib.c still contains logic to call functions from AmdSev.c based on s= ome AMD specific check. In my opinion, that's already good enough. However, if you check MdeModulePkg/DxeIpl, implementations for different ar= chs are in different *folders*. Can we leave this to the module owner to decide how to place the implementa= tions? 1. When a new arch's implementation is introduced to the existing module= which was developed for the specific arch: 1. The folder reconstruction: * Create arch folder for the existing arch implementation [Ray] Do you move existing arch implementation to that arch folder? It will= break existing platforms a lot. * Create the arch folder for the new introduced arch [Ray] I agree. But if we don't create arch folder for existing arch impleme= ntation, the pkg layout will be a mess. [Ray] Hard for me to understand all the principles here. Maybe we review ex= isting code including to-be-upstreamed code and decide how to go. 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_MWHPR11MB16319AA74D5CD0051CA8ED7E8C549MWHPR11MB1631namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

[Ray] Looks good.=

 

  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

[Ray]  “Cpu= Dxe.inf” and “CpuDxeArm.inf”? is that your intention? New= developers may be confused that CpuDxe.inf supports only X86 arch.

Do you have an example= that one module supporting multiple archs using different INF files? MdeMo= dulePkg/DxeIpl is a module supporting different archs with the same INF fil= e.

Or shall we leave it t= o be decided between the patch contributor and package/module maintainer?

 

        &= 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

[Ray] If you check the= MpInitLib, most of SEV logic are moved to AmdSev.c. But MpLib.c still cont= ains logic to call functions from AmdSev.c based on some AMD specific check= . In my opinion, that’s already good enough.

However, if you check = MdeModulePkg/DxeIpl, implementations for different archs are in different *= folders*.

Can we leave this to t= he module owner to decide how to place the implementations?

 

 

  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>

    [Ray] Do you move exis= ting arch implementation to that arch folder? It will break existing platfo= rms a lot.

    • Create the arch folder for the new introduced arch
      • <= /ul>

      [Ray] I agree. But if = we don’t create arch folder for existing arch implementation, the pkg= layout will be a mess.

       

      [Ray] Hard for me to u= nderstand all the principles here. Maybe we review existing code including = to-be-upstreamed code and decide how to go.

       

      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_MWHPR11MB16319AA74D5CD0051CA8ED7E8C549MWHPR11MB1631namp_--