Marvin, Thanks for the detailed feedback. I have attempted to address each of your points. Please let me know if I missed anything.
* IntelFspPkg and IntelFspWrapperPkg: I moved them to Deprecated based on feedback to the first version of this RFC from Jiewen Yao. However, I do agree with your point that it may be too early to categorize those packages in Deprecated and it would likely not make sense until there are a number of platforms using the IntelFsp2Pkg and IntelFsp2WrapperPkg. I will update for RFC V3. * IntelFsp*Pkg: I agree that FSP is Intel specific and all FSP packages should be in an Intel specific directory. I will update for RFC V3. * EdkCompatibilityPkg: I agree that this package is useful if you are using EDK I source modules. However, we do want to encourage the use of EDK II source modules and for developers to port their valuable EDK I source modules to EDK II. Just because this package is in Deprecated does not mean it will be deleted soon or without notice. Before any package is deleted from edk2/master, we would have a proposal and time line discussion on edk2-devel. * CorebootModulePkg: I moved the CorebootPlatformPkg to Platform in V2 because it has DSC/FDF. I think it may be reasonable to move CorebootModulePkg to either Drivers or next to CorebootPlatformPkg in Platform. I would like to see feedback from Coreboot*Pkg maintainers on their preference and I will update for RFC V3. * UefiCpuPkg: The original intent of this package was to provide support for all CPUs that have ABIs documented in the UEFI Specification. I agree with the observation that the current version of this package only contains support for IA32/X64 CPUs. If there is interest in adding more CPUs to this package, then I would prefer to keep it in Silicon/Common. There are no hard dependencies between UefiCpuPkg and FSP. OVMF and Quark use UefiCpuPkg without an FSP. Platforms that do use an FSP may choose to use some content from UefiCpuPkg. * Meaning of 'Deprecated': This directory is there to make sure the EDK II Community knows to avoid using packages from that directory if possible. The timeline for removing a package from edk2/master is something that will always be a thoughtful discussion on edk2-devel. For platforms that do depend on packages that rotate through Deprecated and are eventually retired from edk2/master, the recommendation will be for those platforms to be maintained against an EDK II release/tag or UDK 20xx release that provides a fully validated and supported versions of those packages. This is how we can support and encourage use of latest technologies in edk2/master and provide compatibility with older technologies through validated releases. I look forward to additional feedback on this topic of the Deprecated directory and the concept of retiring packages from edk2/master over time. I think adding the 'Deprecated' directory in this proposal is a good way to get this conversation started and make sure that everyone's input is captured. Thanks, Mike > -----Original Message----- > From: Marvin H?user [mailto:[email protected]] > Sent: Thursday, May 26, 2016 3:56 AM > To: [email protected] > Cc: Kinney, Michael D <[email protected]> > Subject: RE: [edk2] [RFC V2] Proposal to organize packages into directories > > Hey Mike, > > Thank you very much for your effort of introducing a new directory structure, > it looks > very nice so far! > > Though, may I ask why IntelFspPkg and IntelFspWrapperPkg are now deprecated? > If 'deprecated' does not mean that the packages are likely to be removed, but > just > means, if possible, developers should stop using it, then you can skip this > paragraph. > I don't know what Intel is sharing with its partners as I am none, but on the > public > site, even the Broadwell FSP is still v1.0 and there are only a few following > the v1.1 > specification. To me, "deprecated" sounds like the package will eventually be > removed, > but that maybe wouldn't be a good idea for these as, publicly, there isn't > even a > single FSP 2.0 release. Also, the "Compatibility" part of EdkCompatibilityPkg > shouldn't > be deprecated either, in my opinion, as it is a nice resource for easy-to-use > backwards-compatibility. > > Furthermore, I recall someone already brought up that 'CorebootModulePkg' > should > probably not be part of the 'Core' directory as it isn't 'Platform agnostic'. > Didn't > you actually list them as part of 'Platform' in a reply to your V1 concept, > as well as > IntelFsp2Pkg and IntelFsp2WrapperPkg? The FSP packages should probably go in > the same > directory as UefiCpuPkg, because to me UefiCpuPkg seems to be just an Open > Source part > of FSP, isn't it that way? These three should, in my opinion, go to the Intel > directory, as UefiCpuPkg only supports Intel code for now anyway... except if > you are > planning to merge ARM and other architecture's code into UefiCpuPkg in the > future. > > Thank you for your time! > > Regards, > Marvin. > > > -----Original Message----- > > From: edk2-devel [mailto:[email protected]] On Behalf Of > > Kinney, Michael D > > Sent: Thursday, May 26, 2016 4:04 AM > > To: [email protected]; Kinney, Michael D > > <[email protected]> > > Subject: [edk2] [RFC V2] Proposal to organize packages into directories > > > > Hello, > > > > I have gone through all the feedback I have received and have updated this > > proposal. Here is a summary of the changes in V2: > > > > * IntelFrameworkModulePkg -> Deprecated > > * IntelFrameworkPkg -> Deprecated > > * IntelFspPkg -> Deprecated > > * IntelFspWrapperPkg -> Deprecated > > * PerformancePkg -> Deprecated > > * CorebootPayloadPkg -> Platform > > * EmbeddedPkg -> Driver > > * ArmPlatformPkg/ArmJunoPkg -> Silicon/Arm/ArmJunoPkg > > * ArmPlatformPkg/ArmVExpressPkg -> Silicon/Arm/ ArmVExpressPkg > > * Change Drivers to Driver so no top level directories are plural. > > * Remove Vendor directory from Silicon and Platform to reduce directory > > depth > > * Add Platform/Common directory for non-vendor specific platform > > packages > > * Add Silicon/Common directory for non-vendor specific packages of > > CPU/Chipset/SoC drivers > > * Keep Vendor directory in Driver. > > Non-vendor specific packages of drivers are flat just below Driver. > > Provides area to migrate non-vendor specific drivers from Core over time > > > > Please let me know if I missed any feedback and if there is new feedback on > > this revised proposal for the directory structure or the directory names. > > > > <proposal> > > > > # EDK II - Proposal to organize packages into directories > > > > There have been some discussions about organizing packages into > > directories. > > Below is a proposal for a top level directory structure and a first pass > > mapping > > of the packages from edk2/master. Where applicable, vendor specific > > directories can be added. > > > > The PACKAGES_PATH feature documented in the link below is used to > > support this proposed directory structure with no source file changes. An > > example of setting PACKAGES_PATH in a windows environment is also > > shown below and I have verified that platforms can be built using this > > proposal. > > > > https://github.com/tianocore/tianocore.github.io/wiki/Multiple_Workspace > > > > Please provide feedback on the proposal (for, against, alternate proposal), > > the number/type of top level directories, and the top level directory names. > > > > I have setup a branch with this directory structure in this proposal to help > > with the review. I have verified that I can build some platforms in this > > branch > > using the PACKAGES_PATH settings shown below. > > > > https://github.com/mdkinney/edk2/tree/NewDirStruct > > > > > > # Top Level Directory Structure (Listed Alphabetically) ``` > > edk2 > > Application Applications and application support libraries > > BaseTools EDK II build tools/scripts > > Conf EDK II build configuration files > > Core Platform agnostic packages for core FW services > > Deprecated Packages that will be removed from edk2/master soon > > Driver EDK II Drivers (no platform assumptions) > > <Package1> Non-Vendor specific EDK II drivers > > <Package2> Non-Vendor specific EDK II drivers > > . . . > > Vendor Vendor specific EDK II drivers > > <VendorA> > > <VendorB> > > Platform Platforms used to validate edk2/master features > > Common Non-vendor specific platform packages > > Emulated Non-vendor specific emulated platform packages > > Arm ARM specific platform packages > > Intel Intel specific platform packages > > <VendorM> <VendorM> specific platform packages > > <VendorN> <VendorN> specific platform packages > > Silicon CPU/Chipset/SoC packages > > Common Non-vendor specific CPU/Chipset/SoC drivers > > Arm Arm specific CPU/Chipset/SoC drivers > > Intel Intel specific CPU/Chipset/SoC drivers > > <VendorX> <VendorX> specific CPU/Chipset/SoC drivers > > <VendorY> <VendorY> specific CPU/Chipset/SoC drivers > > ``` > > > > # Mapping packages from edk2/master into proposed directory structure ``` > > edk2 > > Application > > AppPkg > > ShellPkg > > StdLib > > StdLibPrivateInternalFiles > > Core > > CorebootModulePkg > > CryptoPkg > > IntelFsp2Pkg > > IntelFsp2WrapperPkg > > MdeModulePkg > > MdePkg > > SecurityPkg > > SourceLevelDebugPkg > > Deprecated > > EdkCompatibilityPkg > > EdkShellBinPkg > > EdkShellPkg > > FatBinPkg > > IntelFrameworkModulePkg > > IntelFrameworkPkg > > IntelFspPkg > > IntelFspWrapperPkg > > PerformancePkg > > ShellBinPkg > > Driver > > EmbeddedPkg > > FatPkg > > NetworkPkg > > OptionRomPkg > > Vendor > > Platform > > Common > > DuetPkg > > OvmfPkg > > CorebootPayloadPkg > > Emulated > > EmulatorPkg > > Nt32Pkg > > UnixPkg > > Arm > > ArmPlatformPkg > > ArmVirtPkg > > BeagleBoardPkg > > Intel > > QuarkPlatformPkg > > Vlv2TbltDevicePkg > > Silicon > > Common > > PcAtChipsetPkg > > UefiCpuPkg > > Arm > > ArmPkg > > ArmJunoPkg > > ArmVExpressPkg > > Omap35xxPkg > > Intel > > QuarkSocPkg > > Vlv2DeviceRefCodePkg > > ``` > > > > # Setting PACKAGES_PATH to support builds using proposed directory > > structure ``` set > > PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Core > > set PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Driver > > set > > PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Silicon\Arm > > set > > PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Silicon\Com > > mon > > set > > PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Silicon\Intel > > set > > PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Platform\Ar > > m > > set > > PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Platform\Co > > mmon > > set > > PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Platform\Em > > ulated > > set > > PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Platform\Int > > el > > set > > PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Application > > set > > PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Deprecated > > set PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2 > > ``` > > > > </proposal> > > > > Best regards, > > > > Mike > > _______________________________________________ > > edk2-devel mailing list > > [email protected] > > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
