> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
> Ersek
> Sent: Tuesday, January 29, 2019 7:12 PM
> To: Ni, Ray <ray...@intel.com>; edk2-devel@lists.01.org
> Cc: Zimmer, Vincent <vincent.zim...@intel.com>; Wolman, Ayellet
> <ayellet.wol...@intel.com>; Cetola, Stephano <stephano.cet...@intel.com>;
> Kinney, Michael D <michael.d.kin...@intel.com>
> Subject: Re: [edk2] [RFC] Proposal to split Pkgs
>
> 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.
That's great to have feedbacks in the early phase.
>
> (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.
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?
>
> 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.
Thanks for providing your thoughts about the code size. And the code size data
of
QEMU/Linux is helpful.
>
> 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.
>
> Thanks
> Laszlo
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
