Re: [RFC] Proposal to split Pkgs

[Laszlo Ersek <lersek@redhat.com>]

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