Paolo, For this proposal, I am not only looking at existing packages/modules/libs, I am also considering where new content might go over time. For example, the MdeModulePkg has grown in size over the years. The PEI Core, DXE Core, SMM Core content in MdeModulePkg is "Core" content, but much of the other content in that package would really fall into the "Drivers" category. Instead of adding more content to MdeModulePkg in the future, we should consider adding it to "Drivers" instead.
There have also been questions on edk2-devel on where to add vendor specific drivers for devices/peripherals that attach to PCI/USB/I2C/etc. "Drivers" seems like a better location than "Silicon". We could even consider in the future figuring out ways to move some of the content out packages like MdeModulePkg into "Drivers". So instead of removing "Drivers" from the proposal because there are only a couple packages in that category today, let's keep it and make sure we add new content to the right directory going forward. Mike > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Paolo > Bonzini > Sent: Thursday, May 19, 2016 10:21 AM > To: Kinney, Michael D <michael.d.kin...@intel.com>; Ryan Harkin > <ryan.har...@linaro.org> > Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org> > Subject: Re: [edk2] [RFC] Proposal to organize packages into directories > > > > On 19/05/2016 18:21, Kinney, Michael D wrote: > > This is one of the reasons I wanted to have both a "Silicon" and a "Driver" > > top level directory. > > > > We can change names, but the idea is that the "Silicon" one would contains > > CPU/Chipset/SoC content that is usually contains the drivers to init the CPU > > complex, turn on caches, enable memory subsystems, and do basic init of the > > I/O subsystems built into the CPU/Chipset/SoC. > > > > The "Drivers" area is for modules that manage hardware and peripherals that > > attach to standard I/O subsystems such as PCI, USB, I2C, etc. > > Okay, that makes sense. Indeed they are different, for example outside > Silicon/ the architecture is not particularly important. > > At the same time, with Drivers/ reduced to just three packages, I wonder > if it would make sense to move FatPkg and NetworkPkg to Core/, and > OptionRomPkg to Silicon/. Most drivers are part of MdeModulePkg, which > is in Core/. > > For Silicon/, I think <Architecture>/<Vendor>/FooPkg (which can be > reduced to <Architecture>/FooPkg or even just FooPkg) can be more useful > than Vendor/<Vendor>/FooPkg. This would give > > Silicon/ > Arm/ (architecture) > ArmPkg > ArmPlatformPkg > ArmVirtPkg > Arm/ (vendor) > ArmJunoPkg (currently in ArmPlatformPkg/ArmJunoPkg) > ArmVExpressPkg (currently in ArmPlatformPkg/ArmVExpressPkg) > Omap35xxPkg > IA32X64/ > CorebootModulePkg > PcAtChipsetPkg > UefiCpuPkg > Intel/ > QuarkSocPkg > Vlv2DeviceRefCodePkg > OptionRomPkg > > > If we have an area for CPU/Chipset/SoC, then we can use some directory paths > > that clearly identify CPU architecture content as well as a Vendor specific > > content. > > > > I would hope we can concentrate the CPU architecture content that applies to > > all vendors in its own area, and only the vendor specific extensions go into > > vendor specific directories. > > This sounds good! > > Thanks, > > Paolo > _______________________________________________ > 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
