From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=17.151.62.68; helo=nwk-aaemail-lapp03.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (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 61421211BA47E for ; Thu, 31 Jan 2019 05:09:33 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x0VD6Lou065150; Thu, 31 Jan 2019 05:09:32 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=D2BF3GPOOZHx8Kvc6D2V/DRfOYfEnOm4Q4DzqObbkfY=; b=hb7DWkkdv2QkUop/id7GMPsi0oFPCFCHgq4NJ+if25eU2MvR7lM56/Gt1sZ4Zba9boxy eyY4DPKAGYgYMvS8ItfhwYfskQFgjcCC8YMbL2jMv+Q3kSARQ4b18SKCep5FYsTGMBPj iT4m/wC6ktJbF/73rLATOBqtxg6NBPgW8rNE1to+pLd5l/hIIgtXPp+jpT+XSTumvYEF DzdULPDMCt2HwpDpq6NI3DcPXBQxYiCHY00NsPWMZjheaJJn6fO47NIKemC68UMgYdH1 pgCFQC7zybVfnTiZTfGV0etif1U46/oHle06fp0SlWVNWrGAHntkqUrkuEMg05lMsfML EA== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2q98343419-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 31 Jan 2019 05:09:32 -0800 MIME-version: 1.0 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PM7008J25VVA890@ma1-mtap-s02.corp.apple.com>; Thu, 31 Jan 2019 05:09:31 -0800 (PST) Received: from process_viserion-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PM700B005ELPO00@nwk-mmpp-sz13.apple.com>; Thu, 31 Jan 2019 05:09:31 -0800 (PST) X-Va-A: X-Va-T-CD: 81ca60fce39c2560b6c4a7e5841f9b8f X-Va-E-CD: 32161a353fcb6186c5b5af5423fc89fa X-Va-R-CD: 9c26a2d2d404ea6f389ae5c139927d69 X-Va-CD: 0 X-Va-ID: 6aadead7-e0e2-4519-ac66-9ef479a59fe2 X-V-A: X-V-T-CD: 81ca60fce39c2560b6c4a7e5841f9b8f X-V-E-CD: 32161a353fcb6186c5b5af5423fc89fa X-V-R-CD: 9c26a2d2d404ea6f389ae5c139927d69 X-V-CD: 0 X-V-ID: 589ba5ee-f959-4a37-bc1d-5e710be5b289 Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PM700D005G1FO00@nwk-mmpp-sz13.apple.com>; Thu, 31 Jan 2019 05:09:31 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-01-31_07:,, signatures=0 Received: from [17.234.47.246] (unknown [17.234.47.246]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PM70083B5VUK640@nwk-mmpp-sz13.apple.com>; Thu, 31 Jan 2019 05:09:31 -0800 (PST) Sender: afish@apple.com From: Andrew Fish In-reply-to: <734D49CCEBEEF84792F5B80ED585239D5BFF82D7@SHSMSX104.ccr.corp.intel.com> Date: Thu, 31 Jan 2019 05:09:26 -0800 Cc: "edk2-devel@lists.01.org" , Mike Kinney , Vincent Zimmer , Laszlo Ersek , "Cetola, Stephano" , "leif.lindholm@linaro.org" , "Wolman, Ayellet" Message-id: <8E18BF87-7E49-4E66-85E1-FA362398AF8F@apple.com> References: <734D49CCEBEEF84792F5B80ED585239D5BFF82D7@SHSMSX104.ccr.corp.intel.com> To: "Ni, Ray" X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-31_07:, , signatures=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: Thu, 31 Jan 2019 13:09:33 -0000 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII > On Jan 28, 2019, at 9:59 PM, Ni, Ray wrote: > > Hello, > I'd like to propose to split today's BIG packages in following ways: > > ==============Overview ================= > > 1. Separate Industry standard definitions from UEFI and PI interfaces. Ray, >>From a big picture point of view lets talk about customer impact.... Splitting the MdePkg means: 1) Every INF file needs a new [Packages] layout, so has to change. 2) Every DSC file needs to update [LibraryClasses] pathing. Moving the drivers around: 1) Every DSC file has to change to update the path to the driver 2) Every FDF file has to change to update the path to the driver. I'd point out forcing every 3rd party module (library, driver, or application) to change is a much bigger impact that forcing a change to a projects target platform (DSC, FDF). I'm trying to figure out how to make a common code base that spans several generations of vendor code. So obviously today every module depends of MdePkg, and each new product is going to require new drivers for the chipset and peripherals. So lets say I'm a 3rd party graphics vendor does this mean I need and edk2 version of an INF and an edk3 version (no more MdePkg) of the INF as my customers are going to move at different rates? On the flip side how do I make a common platform tree if my vendor for work station chipsets lags behind my other chipset vendor in regards to moving to edk3. Does that mean I have to port that vendors code to edk3, which does not sound bad until you realize that every code drop from the vendor I need to remerge my edk3 changes back on top of it. Seems like a lot of work. Thus I think we need to ask the question do we need to leave the MdePkg around for compatibility? Do we need an INF syntax that supports edk2 and edk3 (Like the #ifdef we had that supported EDK and edk2 includes back in the day). We could have edk2 and edk3 INF files for very module? Do we need to build a synthetic MdePkg that gets you the correct packages paths for the new include layout? I guess we could just make MdePkg an alias in the INF file for the 3 (?) new packages? Or do we not change all the include paths? Seems like we are creating our own Python 2.* vs. 3.* mess to make it easier to maintain the packages? I'm not saying it is wrong, but we should ask the question how is going to impact the edk2 consumers. Thanks, Andrew Fish > 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? > > ==============More explanations ================= > > ####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 > Layer 3: PiDxePkg > Layer 4: PiMmPkg > Layer 5: MdeModulePkg (TianoPkg?) > > ####All other modules are put to small packages under Device/ or Feature/. > > ============== Benefit of this proposal ================= > > 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 >