From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.93; helo=mga11.intel.com; envelope-from=ray.ni@intel.com; receiver=edk2-devel@lists.01.org Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (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 66988211A6D56 for ; Tue, 29 Jan 2019 05:13:44 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jan 2019 05:13:43 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,537,1539673200"; d="scan'208";a="295357600" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga005.jf.intel.com with ESMTP; 29 Jan 2019 05:13:43 -0800 Received: from fmsmsx114.amr.corp.intel.com (10.18.116.8) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 29 Jan 2019 05:13:41 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by FMSMSX114.amr.corp.intel.com (10.18.116.8) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 29 Jan 2019 05:13:40 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.102]) by shsmsx102.ccr.corp.intel.com ([169.254.2.207]) with mapi id 14.03.0415.000; Tue, 29 Jan 2019 21:13:38 +0800 From: "Ni, Ray" To: Laszlo Ersek , "edk2-devel@lists.01.org" CC: "Zimmer, Vincent" , "Wolman, Ayellet" , "Cetola, Stephano" , "Kinney, Michael D" Thread-Topic: [edk2] [RFC] Proposal to split Pkgs Thread-Index: AdS3j0052ugHs20hTdOAPxXXz73cZ///4ieA//9ZdqA= Date: Tue, 29 Jan 2019 13:13:37 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5BFFB5BF@SHSMSX104.ccr.corp.intel.com> References: <734D49CCEBEEF84792F5B80ED585239D5BFF82D7@SHSMSX104.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US, zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMWUxMzg4OTUtNGM3ZS00ZDM1LWJjOTgtYmFlYmUxZjIyZDdmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiRzdqRU80TUhWRDN6NEtUM0duV2Z6S3E1amIwZ1JYWjdLZVRqRTRqSWpmOVwvNVhOa3B2d2FmZVIzSVNoZysweVUifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [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 13:13:44 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of La= szlo > Ersek > Sent: Tuesday, January 29, 2019 7:12 PM > To: Ni, Ray ; edk2-devel@lists.01.org > Cc: Zimmer, Vincent ; Wolman, Ayellet > ; Cetola, Stephano ; > Kinney, Michael D > Subject: Re: [edk2] [RFC] Proposal to split Pkgs >=20 > Hi Ray, >=20 > On 01/29/19 06:59, Ni, Ray wrote: > > 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 packag= e. > > 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 > > Layer 3: PiDxePkg > > Layer 4: PiMmPkg > > Layer 5: MdeModulePkg (TianoPkg?) > > > > ####All other modules are put to small packages under Device/ or Featur= e/. > > > > =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. >=20 > from a first / quick skim, it sounds OK to me; however, I'd like to expli= citly defer > on this to the other stewards & stakeholders. I remember that Leif had id= eas > about reorganizing the tree. That's great to have feedbacks in the early phase. >=20 > (Also, I vaguely feel that the movement/renaming of some macros / definit= ions > that Andrew and Mike have been discussing in thread >=20 > [edk2] History question about Base.h and its alternate parallel name > space.... Should we change it? >=20 > might overlap with this reorg.) >=20 > Regarding the benefits, I agree that we need clearer / finer grained assi= gnments > between modules / packages and maintainers. I'm unsure if that really req= uires > reorganizing the tree (we could just reorganize Maintainers.txt instead -= - add > some pathname patterns), but I agree that reorganizing the tree is one me= thod > that could work. I agree adding more information in Maintainers.txt works as well. Thanks for providing the "pathname pattern" idea. I may do that in parallel to find more maintainers for MdeModulePkg. Do you agree to have more than 2 maintainers for MdeModulePkg? >=20 > Regarding sparse git checkout -- I'm probably missing details of this git= feature > itself (regardless of subject project), but I'm generally indifferent / u= nexcited > about this. On my disk, a clean QEMU tree is twice as large as edk2, and = a clean > Linux tree is more than thrice as large. Also, it's been years since I de= cided it was > impossible for me to work without a good SSD (i.e. that traditional spind= le disks > would be way too slow.) So, if the reorg helps some developers with handl= ing > the tree locally, I don't mind, but personally I don't consider the reorg= a benefit > for that. Thanks for providing your thoughts about the code size. And the code size d= ata of QEMU/Linux is helpful. >=20 > Again, I'd like to leave the specifics to Leif, Mike, and others. I hope = that's > acceptable. Thank you very much for your quick response. >=20 > Thanks > Laszlo > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel