Re: [edk2] [RFC] Proposal to organize packages into directories

[Paolo Bonzini]

On 19/05/2016 20:21, Kinney, Michael D wrote:
> 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".

That would be even better. :)

Paolo

> 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 //FooPkg (which can be
>> reduced to /FooPkg or even just FooPkg) can be more useful
>> than 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

Re: [edk2] [RFC] Proposal to organize packages into directories

[Kinney, Michael D]

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 //FooPkg (which can be
> reduced to /FooPkg or even just FooPkg) can be more useful
> than 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

Re: [edk2] [RFC] Proposal to organize packages into directories

[Paolo Bonzini]

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 //FooPkg (which can be
reduced to /FooPkg or even just FooPkg) can be more useful
than 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

Re: [edk2] [RFC] Proposal to organize packages into directories

[Kinney, Michael D]

Paolo,

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.

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.

Mike


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Paolo 
> Bonzini
> Sent: Thursday, May 19, 2016 9:06 AM
> To: Ryan Harkin <ryan.har...@linaro.org>
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org 
>  de...@ml01.01.org>
> Subject: Re: [edk2] [RFC] Proposal to organize packages into directories
> 
> 
> 
> On 19/05/2016 18:03, Ryan Harkin wrote:
> > > IA32X64 is not a great name, but neither is Intel.  X86 suggests 32-bit
> > > only.
> >
> > I prefer the idea of separating by vendor.  One vendor may have
> > multiple architectures, for example.
> 
> That's exactly why I want to separate by architecture. :)
> 
> When doing a change across the entire tree, it's way more common to care
> about 'all ARM boards' than 'all SoCs from Qualcomm'.
> 
> 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

Re: [edk2] [RFC] Proposal to organize packages into directories

[Paolo Bonzini]

On 19/05/2016 18:03, Ryan Harkin wrote:
> > IA32X64 is not a great name, but neither is Intel.  X86 suggests 32-bit
> > only.
>
> I prefer the idea of separating by vendor.  One vendor may have
> multiple architectures, for example.

That's exactly why I want to separate by architecture. :)

When doing a change across the entire tree, it's way more common to care
about 'all ARM boards' than 'all SoCs from Qualcomm'.

Thanks,

Paolo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] Proposal to organize packages into directories

[Ryan Harkin]

On 19 May 2016 at 14:35, Paolo Bonzini  wrote:
>
>
> On 18/05/2016 01:57, Kinney, Michael D wrote:
>>   Core
>> CorebootModulePkg
>> CorebootPayloadPkg
>
> I think that anything with a .fdf file should be under Platform.
> CorebootPayloadPkg is the only outlier in your proposal.
>
>> Emulated
>>   DuetPkg
>>   EmulatorPkg
>>   Nt32Pkg
>>   OvmfPkg
>
> I think OvmfPkg is not emulated; certainly not in the same sense as
> EmulatorPkg, Nt32 or UnixPkg.  DuetPkg also seems more similar to
> OvmfPkg than to EmulatorPkg (and definitely most similar to
> CorebootPayloadPkg, which should be under Platform according to the rule
> I proposed above).
>
> In addition, I think that separation by architecture is more useful than
> separation by vendor.  This yields the following:
>
> Platform
>   Arm
> ArmPlatformPkg
> ArmVirtPkg
> BeagleBoardPkg
>   Emulated
> EmulatorPkg
> Nt32Pkg
> UnixPkg
>   IA32X64
> CorebootPayloadPkg
> DuetPkg
> Intel
>   QuarkPlatformPkg
>   Vlv2TbltDevicePkg
> OvmfPkg
>
> IA32X64 is not a great name, but neither is Intel.  X86 suggests 32-bit
> only.
>

I prefer the idea of separating by vendor.  One vendor may have
multiple architectures, for example.

But I'm also not keen on the "Vendor" sub-dir itself, it seems redundant:

  Platform/Vendor/ARM
vs
  Platform/ARM

OK, so the emulated platforms don't have a "vendor" as such, but
"Emulated" could be as good a name as any.


> In addition, I am not sure about the separation between "Drivers" and
> "Silicon".  My proposal here is to unify them as follows:
>
> Drivers
>   FatPkg
>   NetworkPkg
>   OptionRomPkg
>   Arm
> ArmPkg
> Omap35xxPkg
>   IA32X64
> PcAtChipsetPkg
> QuarkSocPkg
> UefiCpuPkg
> Vlv2DeviceRefCodePkg
>
> or alternatively Omap35xxPkg, QuarkSocPkg and Vlv2DeviceRefCode could
> move under Drivers/Vendor/{Arm,Intel}.
>
> 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

Re: [edk2] [RFC] Proposal to organize packages into directories

[Paolo Bonzini]

On 18/05/2016 01:57, Kinney, Michael D wrote:
>   Core
> CorebootModulePkg
> CorebootPayloadPkg

I think that anything with a .fdf file should be under Platform.
CorebootPayloadPkg is the only outlier in your proposal.

> Emulated
>   DuetPkg
>   EmulatorPkg
>   Nt32Pkg
>   OvmfPkg

I think OvmfPkg is not emulated; certainly not in the same sense as
EmulatorPkg, Nt32 or UnixPkg.  DuetPkg also seems more similar to
OvmfPkg than to EmulatorPkg (and definitely most similar to
CorebootPayloadPkg, which should be under Platform according to the rule
I proposed above).

In addition, I think that separation by architecture is more useful than
separation by vendor.  This yields the following:

Platform
  Arm
ArmPlatformPkg
ArmVirtPkg
BeagleBoardPkg
  Emulated
EmulatorPkg
Nt32Pkg
UnixPkg
  IA32X64
CorebootPayloadPkg
DuetPkg
Intel
  QuarkPlatformPkg
  Vlv2TbltDevicePkg
OvmfPkg

IA32X64 is not a great name, but neither is Intel.  X86 suggests 32-bit
only.

In addition, I am not sure about the separation between "Drivers" and
"Silicon".  My proposal here is to unify them as follows:

Drivers
  FatPkg
  NetworkPkg
  OptionRomPkg
  Arm
ArmPkg
Omap35xxPkg
  IA32X64
PcAtChipsetPkg
QuarkSocPkg
UefiCpuPkg
Vlv2DeviceRefCodePkg

or alternatively Omap35xxPkg, QuarkSocPkg and Vlv2DeviceRefCode could
move under Drivers/Vendor/{Arm,Intel}.

Thanks,

Paolo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] Proposal to organize packages into directories

[Yao, Jiewen]

Hi Mike
I think the high level hierarchy is good.

I have some questions below:
1) CorebootModulePkg/CorebootPayloadPkg:
I am not sure if it is proper to put these to "Core" dir.
I think it seems payload for Coreboot platform only. Can we put to "Platform" 
dir, like OVMF?

2) EmbeddedPkg:
I am not sure if the position of the EmbeddedPkg.
I have seems some device drivers - Isp1761UsbDxe/Lan9118Dxe/SataSiI3132Dxe, 
some APP - AndroidFastboot.

Is that really "Core" module?

Maybe can we define the criteria for "core" at first? Then we decide which 
Package should be in there.

My proposal is: only architecture independency module can be in "core".

3) IntelFrameworkPkg/IntelFrameworkModulePkg/IntelFspPkg/IntelFspWrapperPkg:
We do not encourage any new platform use these modules (like 
EdkCompatibilityPkg), so can we put them to "deprecated" dir?

Thank you
Yao Jiewen

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Kinney, Michael D
> Sent: Wednesday, May 18, 2016 7:57 AM
> To: edk2-devel@lists.01.org; Kinney, Michael D
> <michael.d.kin...@intel.com>
> Subject: [edk2] [RFC] Proposal to organize packages into directories
> 
> Hello,
> 
> 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.
> 
> 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
>   DeprecatedPackages that will be removed from edk2/master
> soon
>   Drivers   EDK II Drivers (no platform assumptions)
> Vendor  Vendor specific EDK II drivers
>   
>   
>   Platform  Platforms used to validate edk2/master features
> EmulatedEmulated platform packages
> Vendor  Vendor specific platform packages
>   
>   
>   Silicon   CPU/Chipset/SoC packages
> Vendor  Vendor specific CPU/Chipset/SoC drivers
>   
>   
> 
> Mapping packages from edk2/master into proposed directory structure
> ==
> =
> edk2
>   Application
> AppPkg
> ShellPkg
> StdLib
> StdLibPrivateInternalFiles
>   Core
> CorebootModulePkg
> CorebootPayloadPkg
> CryptoPkg
> EmbeddedPkg
> IntelFrameworkModulePkg
> IntelFrameworkPkg
> IntelFsp2Pkg
> IntelFsp2WrapperPkg
> IntelFspPkg
> IntelFspWrapperPkg
> MdeModulePkg
> MdePkg
> PerformancePkg
> SecurityPkg
> SourceLevelDebugPkg
>   Deprecated
> EdkCompatibilityPkg
> EdkShellBinPkg
> EdkShellPkg
> FatBinPkg
> ShellBinPkg
>   Drivers
> FatPkg
> NetworkPkg
> OptionRomPkg
> Vendor
>   Platform
> Emulated
>   DuetPkg
>   EmulatorPkg
>   Nt32Pkg
>   OvmfPkg
>   UnixPkg
> Vendor
>   Arm
> ArmPlatformPkg
> ArmVirtPkg
> BeagleBoardPkg
>   Intel
> QuarkPlatformPkg
> Vlv2TbltDevicePkg
>   Silicon
> PcAtChipsetPkg
> UefiCpuPkg
> Vendor
>   Arm
> ArmPkg
> 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\Drivers
> set PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Silicon
> set
> PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Silic

Re: [edk2] [RFC] Proposal to organize packages into directories

[Zeng, Star]

Mike,

Could we put PerformancePkg into the Deprecated directory? As 
PerformancePkg\Library\TscTimerLib could be replaced by 
PcAtChipsetPkg\Library\AcpiTimerLib and ShellPkg\Library\UefiDpLib has the same 
functionality with PerformancePkg\Dp_App.
The valid concern is that user may want a standalone DP application.

Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kinney, 
Michael D
Sent: Wednesday, May 18, 2016 7:57 AM
To: edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
Subject: [edk2] [RFC] Proposal to organize packages into directories

Hello,

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.

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
  DeprecatedPackages that will be removed from edk2/master soon
  Drivers   EDK II Drivers (no platform assumptions)
Vendor  Vendor specific EDK II drivers
  
  
  Platform  Platforms used to validate edk2/master features
EmulatedEmulated platform packages
Vendor  Vendor specific platform packages
  
  
  Silicon   CPU/Chipset/SoC packages
Vendor  Vendor specific CPU/Chipset/SoC drivers
  
  

Mapping packages from edk2/master into proposed directory structure 
===
edk2
  Application
AppPkg
ShellPkg
StdLib
StdLibPrivateInternalFiles
  Core
CorebootModulePkg
CorebootPayloadPkg
CryptoPkg
EmbeddedPkg
IntelFrameworkModulePkg
IntelFrameworkPkg
IntelFsp2Pkg
IntelFsp2WrapperPkg
IntelFspPkg
IntelFspWrapperPkg
MdeModulePkg
MdePkg
PerformancePkg
SecurityPkg
SourceLevelDebugPkg
  Deprecated
EdkCompatibilityPkg
EdkShellBinPkg
EdkShellPkg
FatBinPkg
ShellBinPkg
  Drivers
FatPkg
NetworkPkg
OptionRomPkg
Vendor
  Platform
Emulated
  DuetPkg
  EmulatorPkg
  Nt32Pkg
  OvmfPkg
  UnixPkg
Vendor
  Arm
ArmPlatformPkg
ArmVirtPkg
BeagleBoardPkg
  Intel
QuarkPlatformPkg
Vlv2TbltDevicePkg
  Silicon
PcAtChipsetPkg
UefiCpuPkg
Vendor
  Arm
ArmPkg
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\Drivers
set PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Silicon
set PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Silicon\Vendor\Arm
set PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Silicon\Vendor\Intel
set PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Platform\Emulated
set PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Platform\Vendor\Arm
set PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Platform\Vendor\Intel
set PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Application

Best regards,

Mike

___
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

[edk2] [RFC] Proposal to organize packages into directories

[Kinney, Michael D]

Hello,

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.

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
  DeprecatedPackages that will be removed from edk2/master soon
  Drivers   EDK II Drivers (no platform assumptions)
Vendor  Vendor specific EDK II drivers
  
  
  Platform  Platforms used to validate edk2/master features
EmulatedEmulated platform packages
Vendor  Vendor specific platform packages
  
  
  Silicon   CPU/Chipset/SoC packages
Vendor  Vendor specific CPU/Chipset/SoC drivers
  
  

Mapping packages from edk2/master into proposed directory structure
===
edk2
  Application
AppPkg
ShellPkg
StdLib
StdLibPrivateInternalFiles
  Core
CorebootModulePkg
CorebootPayloadPkg
CryptoPkg
EmbeddedPkg
IntelFrameworkModulePkg
IntelFrameworkPkg
IntelFsp2Pkg
IntelFsp2WrapperPkg
IntelFspPkg
IntelFspWrapperPkg
MdeModulePkg
MdePkg
PerformancePkg
SecurityPkg
SourceLevelDebugPkg
  Deprecated
EdkCompatibilityPkg
EdkShellBinPkg
EdkShellPkg
FatBinPkg
ShellBinPkg
  Drivers
FatPkg
NetworkPkg
OptionRomPkg
Vendor
  Platform
Emulated
  DuetPkg
  EmulatorPkg
  Nt32Pkg
  OvmfPkg
  UnixPkg
Vendor
  Arm
ArmPlatformPkg
ArmVirtPkg
BeagleBoardPkg
  Intel
QuarkPlatformPkg
Vlv2TbltDevicePkg
  Silicon
PcAtChipsetPkg
UefiCpuPkg
Vendor
  Arm
ArmPkg
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\Drivers
set PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Silicon
set PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Silicon\Vendor\Arm
set PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Silicon\Vendor\Intel
set PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Platform\Emulated
set PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Platform\Vendor\Arm
set PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Platform\Vendor\Intel
set PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Application

Best regards,

Mike

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel