From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:4864:20::433; helo=mail-wr1-x433.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id E7A44211BB8C0 for ; Tue, 29 Jan 2019 03:39:26 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id v13so21629726wrw.5 for ; Tue, 29 Jan 2019 03:39:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=JghEfOGW2HH6qkhpi2QN9JkIs/UOgq89Qhwg3XSK4Qw=; b=do8KvrkPBQ2VbOx86CGfWUGSkFf5cdE8W6qp8jvTXmD2SQtepYvvL7XTV5tM/maA89 PlW/Bs/v4D48hn8aSqOk4hINk1FH/RLYVglUIipR9oJx5Zjk2JxhABDkib93MKQGTvhv HoMlDybv9GLK964bNrQHfy1RUiSdegTTz3E9o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=JghEfOGW2HH6qkhpi2QN9JkIs/UOgq89Qhwg3XSK4Qw=; b=TlGz5AaY97hf+qc8yya1IA+7i4rVuQwtbWFZPjHRrawRRLmiGf5cJfLHS9kCiYxiMJ OM954ue7RE17DpgxKItFNaFiacOOrKUer7npVKzfjMHIomo6u44YEwI08Q1gk7Q6ZIzL 2biD8NubE4Ekes+6Ttdv+1L0F4zjS4EMNjAV/yKNnldcEjN3IJf8SoBycmSC0UVpX+DM rirtdbgLNd/FMQaCsiMm6/0e+1BZASnLQNW23YPnA56IFj+YeEX5emVgioc16fSnbFiQ GRBG5Jq2+JMX00ojUVkm+2PBrkbts3n1NZvYGidEgivS0+saVFXru1tJOi/4h12nFfxG knTg== X-Gm-Message-State: AJcUukePig2vzKNIsT42qvLTiRexOAdWxNDc2uH2nB4SQOAtTZN0UfFx 8IdAuc8Hxd2aHDQK+Swhal+Jqg== X-Google-Smtp-Source: ALg8bN5BaeBgZ6CerlOAQJ55KP6fbIVr6BpYr0Ms8lxisSGVezgdXJEWIGAQTvR0inBt4aL+/wyvtA== X-Received: by 2002:adf:b649:: with SMTP id i9mr26141479wre.70.1548761964681; Tue, 29 Jan 2019 03:39:24 -0800 (PST) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id g16sm105814643wru.41.2019.01.29.03.39.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 29 Jan 2019 03:39:23 -0800 (PST) Date: Tue, 29 Jan 2019 11:39:21 +0000 From: Leif Lindholm To: Laszlo Ersek Cc: "Ni, Ray" , "edk2-devel@lists.01.org" , "Kinney, Michael D" , "Zimmer, Vincent" , "'Andrew Fish (afish@apple.com)'" , "Cetola, Stephano" , "Wolman, Ayellet" Message-ID: <20190129113921.s5lz7aih73ohv3mw@bivouac.eciton.net> References: <734D49CCEBEEF84792F5B80ED585239D5BFF82D7@SHSMSX104.ccr.corp.intel.com> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) 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:39:27 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Laszlo, Managed to spot this before I sent my own reply :) On Tue, Jan 29, 2019 at 12:11:51PM +0100, Laszlo Ersek wrote: > 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. Heh. Mainly that it needs reorganising :) Although I may have brought up Mike's long-term plans to reorganise on several occasions. > (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? Oh, I've been lax at following the list since I came back off holiday. This looks like a good thread to get stuck into. > 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. I would like both. This split won't resolve the issue of defining separate maintainers for */ARM* and */AARCH64* (and RISCV, ...). But a proper tree rework would help newcomers. Figuring out what goes where is non-trivial effort, and the archaic names don't help with this. > 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. Yeah, I'm with you. Although I guess the issue is more to do with poor network connections than slow checkouts. (Because yes, edk2 is tiny :) > Again, I'd like to leave the specifics to Leif, Mike, and others. I hope > that's acceptable. No problem. / Leif