From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 6F41A211BA46A for ; Tue, 29 Jan 2019 03:11:55 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A7ADA83F3E; Tue, 29 Jan 2019 11:11:54 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-121-45.rdu2.redhat.com [10.10.121.45]) by smtp.corp.redhat.com (Postfix) with ESMTP id 86D3A5F7D8; Tue, 29 Jan 2019 11:11:52 +0000 (UTC) To: "Ni, Ray" , "edk2-devel@lists.01.org" Cc: "Kinney, Michael D" , "Zimmer, Vincent" , "'Andrew Fish (afish@apple.com)'" , "Cetola, Stephano" , "'leif.lindholm@linaro.org'" , "Wolman, Ayellet" References: <734D49CCEBEEF84792F5B80ED585239D5BFF82D7@SHSMSX104.ccr.corp.intel.com> From: Laszlo Ersek Message-ID: Date: Tue, 29 Jan 2019 12:11:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5BFF82D7@SHSMSX104.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 29 Jan 2019 11:11:54 +0000 (UTC) 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 11:11:55 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Hi Ray, On 01/29/19 06:59, 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. > 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. from a first / quick skim, it sounds OK to me; however, I'd like to explicitly defer on this to the other stewards & stakeholders. I remember that Leif had ideas about reorganizing the tree. (Also, I vaguely feel that the movement/renaming of some macros / definitions that Andrew and Mike have been discussing in thread [edk2] History question about Base.h and its alternate parallel name space.... Should we change it? might overlap with this reorg.) Regarding the benefits, I agree that we need clearer / finer grained assignments between modules / packages and maintainers. I'm unsure if that really requires reorganizing the tree (we could just reorganize Maintainers.txt instead -- add some pathname patterns), but I agree that reorganizing the tree is one method that could work. Regarding sparse git checkout -- I'm probably missing details of this git feature itself (regardless of subject project), but I'm generally indifferent / unexcited 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 decided it was impossible for me to work without a good SSD (i.e. that traditional spindle disks would be way too slow.) So, if the reorg helps some developers with handling the tree locally, I don't mind, but personally I don't consider the reorg a benefit for that. Again, I'd like to leave the specifics to Leif, Mike, and others. I hope that's acceptable. Thanks Laszlo