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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
