From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.100; helo=mga07.intel.com; envelope-from=ray.ni@intel.com; receiver=edk2-devel@lists.01.org Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 78630211BA457 for ; Mon, 28 Jan 2019 21:59:48 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jan 2019 21:59:47 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,536,1539673200"; d="scan'208";a="142258075" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by fmsmga001.fm.intel.com with ESMTP; 28 Jan 2019 21:59:39 -0800 Received: from fmsmsx117.amr.corp.intel.com (10.18.116.17) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 28 Jan 2019 21:59:38 -0800 Received: from shsmsx153.ccr.corp.intel.com (10.239.6.53) by fmsmsx117.amr.corp.intel.com (10.18.116.17) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 28 Jan 2019 21:59:38 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.102]) by SHSMSX153.ccr.corp.intel.com ([169.254.12.190]) with mapi id 14.03.0415.000; Tue, 29 Jan 2019 13:59:36 +0800 From: "Ni, Ray" To: "edk2-devel@lists.01.org" CC: "Kinney, Michael D" , "Zimmer, Vincent" , Laszlo Ersek , "'Andrew Fish (afish@apple.com)'" , "Cetola, Stephano" , "'leif.lindholm@linaro.org'" , "Wolman, Ayellet" Thread-Topic: [RFC] Proposal to split Pkgs Thread-Index: AdS3j0052ugHs20hTdOAPxXXz73cZw== Date: Tue, 29 Jan 2019 05:59:35 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5BFF82D7@SHSMSX104.ccr.corp.intel.com> Accept-Language: en-US, zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: [RFC] Proposal to split Pkgs X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 05:59:48 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I'd like to propose to split today's BIG packages in following ways: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DOverview =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Separate Industry standard definitions from UEFI and PI interfaces. 2. Separate UEFI and PI interfaces from implementations. a. Separate UEFI and PI interfaces to different packages b. Separate PI PEI, DXE and MM phase interfaces to different packages 3. Separate different features into feature packages. Feature interface may be in the feature package to provide minimal common interface packages. The POC code is in https://github.com/jyao1/edk2/tree/ReOrg. It basically split the EDKII common code to three directories: Core/, Device/, and Feature/. The code is in very early POC phase and only code in Core/ directory can pass the build. I would like to gather feedbacks through this RFC to see whether this splitting direction makes sense. Is there any other better ways of splitting? Or perhaps do not split in such a small granularity? Or perhaps Mike's work to move lib-c content to edk2-libc repo, to move real platform code to edk2-platform repo is enough for now? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DMore explanations =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ####There are 9 packages inside Core/ directory: 1. BasePkg Contains industry standard definitions (exclude UEFI and PI) and base libraries that non-UEFI and non-PI development can depend on. UEFI or PI development can also depend on this package. 2. UefiPkg Contains UEFI interfaces and libraries that UEFI driver-model driver development can depend on. 3. PiPeiPkg Contains PI interfaces and libraries for PEI phase that PEI module development can depend on. 4. PiDxePkg Contains PI interfaces and libraries for DXE phase that DXE module development can depend on. 5. PiMmPkg Contains PI interfaces and libraries for MM phase that MM/SMM module development can depend on. 6. MdeModulePkg (TianoPkg? Name is still TBD) Contains Tiano implementation specific interfaces and libraries. Developing modules for pure UEFI or PI should not depend on this package. 7. PeiFoundationPkg Contains the PEI foundation modules (PeiCore and DxeIpl) and supported libraries. 8. DxeFoundationPkg Contains the DXE foundation modules (DxeCore and RuntimeDxe) and supported libraries. 9. SmmFoundationPkg Contains the SMM foundation modules (SmmCore, SmmIpl and SmmCommunicationBuffer) and supported libraries. These packages are positioned in different layers. The package in higher layer depends on all packages that are in lower layers. Layer 0: BasePkg. Layer 1: UefiPkg. Layer 2: PiPeiPkg=20 Layer 3: PiDxePkg Layer 4: PiMmPkg Layer 5: MdeModulePkg (TianoPkg?) ####All other modules are put to small packages under Device/ or Feature/. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Benefit of this proposal =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This helps to reduce the size of each package, especially the very BIG MdeModulePkg which contains almost all edk2 modules (except CPU, network, etc). So platform can use git sparse checkout feature to only clone the needed code still in package granularity. This also helps to separate the code maintenance to more expert developers. MdeModulePkg is just too huge to be maintained by 2 or 3 developers. Thanks, Ray