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::441; helo=mail-wr1-x441.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (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 417CE211B5A34 for ; Tue, 29 Jan 2019 06:21:17 -0800 (PST) Received: by mail-wr1-x441.google.com with SMTP id r10so22236477wrs.10 for ; Tue, 29 Jan 2019 06:21:17 -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=xLop65AA0Rg7i3PRHx7thzwiFO73lUuKZwZJks7Mi7c=; b=MzG66MBYCA/7nE3O3JITKh01i9Py1ndG+NvqFoNj61A1yomaGjKEFw1gj1A+dioRtB aubYJWwzIAtyZM4dhpad9iwx6/aMshdvur7TvxQ2u3dumnqxWyZByZTZoIDLOM+AsmeX YgZvtyXX33md9AVCX8bomJZxFHkePxcUoNM7M= 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=xLop65AA0Rg7i3PRHx7thzwiFO73lUuKZwZJks7Mi7c=; b=tJmt7hoKXo62i0QuNrJJYr5RxMxMpZnFUFL9wIwAQtbAMGTSH8ImE9s3jqT2TCDMh9 wiTwlEzAxzYek6x/NETnAs2NPFxpCQ6g9d7Veq3Ju+7s4a/8IIGrbeWJkv0WL8KIxT/D cxLZIBTEWbFRS8ulWRz9rerau7EGKPIfbnKtOnRGh93BfZ+po2cScj3pbs9KpxmpXy1A x7SThB/Exqi3zInr6zs2Bd1RTMkLGdHwKiFb+0KPyjssiEdTZnUr9aapQyVNK6VqyNaB hXG+6zTj3dzajBLzA+4HCGIVC+YswSLwD3Gkk4kNoNjMsjeAfEB7h7I3nYemI0gjOyzY Hz1A== X-Gm-Message-State: AJcUukc0TR6DqjNjqsIzNbYrpLIIHtxQJv84Pj8m/nn+jfD6OGPUvzuP 9YzKKSskgNZokLNRn7xo6aAG7w== X-Google-Smtp-Source: ALg8bN4o1NFAaUGAiV/CbFfguOMCXjZXdJ5ajfW6RHbb1EqmDsC3Kl/mFMWNrguf6RMnCkkykjD2iQ== X-Received: by 2002:a5d:548d:: with SMTP id h13mr24881726wrv.80.1548771675838; Tue, 29 Jan 2019 06:21:15 -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 h17sm112576153wrt.59.2019.01.29.06.21.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 29 Jan 2019 06:21:14 -0800 (PST) Date: Tue, 29 Jan 2019 14:21:13 +0000 From: Leif Lindholm To: "Ni, Ray" Cc: "edk2-devel@lists.01.org" , "Kinney, Michael D" , "Zimmer, Vincent" , Laszlo Ersek , "'Andrew Fish (afish@apple.com)'" , "Cetola, Stephano" , "Wolman, Ayellet" Message-ID: <20190129142113.yxvgoogk2ucgk3aj@bivouac.eciton.net> References: <734D49CCEBEEF84792F5B80ED585239D5BFF82D7@SHSMSX104.ccr.corp.intel.com> MIME-Version: 1.0 In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5BFF82D7@SHSMSX104.ccr.corp.intel.com> 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 14:21:18 -0000 X-List-Received-Date: Tue, 29 Jan 2019 14:21:18 -0000 X-List-Received-Date: Tue, 29 Jan 2019 14:21:18 -0000 X-List-Received-Date: Tue, 29 Jan 2019 14:21:18 -0000 X-List-Received-Date: Tue, 29 Jan 2019 14:21:18 -0000 X-List-Received-Date: Tue, 29 Jan 2019 14:21:18 -0000 X-List-Received-Date: Tue, 29 Jan 2019 14:21:18 -0000 X-List-Received-Date: Tue, 29 Jan 2019 14:21:18 -0000 X-List-Received-Date: Tue, 29 Jan 2019 14:21:18 -0000 X-List-Received-Date: Tue, 29 Jan 2019 14:21:18 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Ray, First of all, thank you for restarting this discussion, and putting the effort in for a POC. On Tue, Jan 29, 2019 at 05:59:35AM +0000, 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/. I'm not sure I like the 'Device' name, but that's not that important at this stage - I like that this is split up the way it is. I also think a lot of things currently under Feture/misc could be broken out into additional subdirectories under 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? I think this would be my only negative(ish) feedback on the POC. While it has the benefit of modules requiring to specify more precisely which functionality they are pulling in... ...it means that they now need to list *everything*. And with the mechanism by which I have seen Intel engineers make use of PACKAGES_PATH in the past*, we end up with a bazillion packages that need to be added individually to this variable for each build. * (arguably how it was designed to be used - just not how I am interested in using it) It also means that we need *tons* of dummy .dsc files in order to run through simple build tests. My preference would be to push the packages back up to the top-level. The split still makes sense, and allocating maintainers to sub-parts can happen without a full-out redesign of the Maintainers.txt format. (Which I will try to resurrect with a proposal over the next few weeks anyway.) > 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? I think we need this further restructuring, and renaming. Not just for splitting up maintainership duties (which as I mentioned in email to Laszlo, we will still need to do with this change). But to make the codebase more approachable. > ==============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. Really happy with the above split. > 5. PiMmPkg > Contains PI interfaces and libraries for MM phase that MM/SMM > module development can depend on. How would/should this work relative to StandaloneMmPkg? > 6. MdeModulePkg (TianoPkg? Name is still TBD) Yes, this needs to be renamed. I don't object to the Tiano naming. > 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. So as a feedback on the whole, this would somewhat help with addressing the confusion caused by PI defining interfaces named EFI_* (which we really ought to address on the spec level at some point). > 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. This looks a bit weird though - surely PI components should not have dependencies on UEFI components? I presume this is what Laszlo referred to with regards to Base.h and the thread from earlier this month. > 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. So, I technically don't care about any of the above, but I still support this proposal (given some additional tweaks). To me, this is all about reflecing boundaries between specification and implementation, as well as boundaries between specfications. Best Regards, Leif