Re: [RFC] Proposal to split Pkgs

[Andrew Fish <afish@apple.com>]

> On Jan 28, 2019, at 9:59 PM, Ni, Ray <ray.ni@intel.com> 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.

Ray,

>From a big picture point of view lets talk about customer impact....

Splitting the MdePkg means:
1) Every INF file needs a new  [Packages] layout, so has to change. 
2) Every DSC file needs to update [LibraryClasses] pathing.

Moving the drivers around:
1) Every DSC file has to change to update the path to the driver
2) Every FDF file has to change to update the path to the driver. 

I'd point out forcing every 3rd party module (library, driver, or application) to change is a much bigger impact that forcing a change to a projects target platform (DSC, FDF). 

I'm trying to figure out how to make a common code base that spans several generations of vendor code. So obviously today every module depends of MdePkg, and each new product is going to require new drivers for the chipset and peripherals. So lets say I'm a 3rd party graphics vendor does this mean I need and edk2 version of an INF and an edk3 version (no more MdePkg) of the INF as my customers are going to move at different rates? On the flip side how do I make a common platform tree if my vendor for work station chipsets lags behind my other chipset vendor in regards to moving to edk3. Does that mean I have to port that vendors code to edk3, which does not sound bad until you realize that every code drop from the vendor I need to remerge my edk3 changes back on top of it. Seems like a lot of work. 

Thus I think we need to ask the question do we need to leave the MdePkg around for compatibility? Do we need an INF syntax that supports edk2 and edk3 (Like the #ifdef we had that supported EDK and edk2 includes back in the day). We could have edk2 and edk3 INF files for very module?  Do we need to build a synthetic MdePkg that gets you the correct packages paths for the new include layout? I guess we could just make MdePkg an alias in the INF file for the 3 (?) new packages? Or do we not change all the include paths?

Seems like we are creating our own Python 2.* vs. 3.* mess to make it easier to maintain the packages? I'm not saying it is wrong, but we should ask the question how is going to impact the edk2 consumers. 

Thanks,

Andrew Fish

> 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.
> 
> Thanks,
> Ray
> <winmail.dat>