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

[Jordan Justen]

On 2016-06-28 03:35:57, Laszlo Ersek wrote:
> 
> Leif recommended "efi-virt" elsewhere, as an arch-less / catch-all name.
> I think I prefer it a bit over ovmf-*: in case ovmf- is
> mentioned, the idea is clear, but if you just want to say "guest UEFI",
> without mentioning the guest arch, "ovmf" would be a bit misleading, due
> to OVMF's historical correspondence to x86.
> 

I don't agree. First of all, the name is generic, and doesn't indicate
a particular architecture, nor VMM. The OvmfPkg/README overview has
always only indicated that our goal is to support 'virtual machines'
for EDK II. All the OVMF releases had the architecture in the released
filename. The .dsc files make it clear that there are different builds
for different architectures.

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

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

[Laszlo Ersek]

On 06/28/16 09:27, Jordan Justen wrote:
> On 2016-06-26 08:44:04, Leif Lindholm wrote:
>>
>> On Fri, Jun 17, 2016 at 10:51:47PM +, Kinney, Michael D wrote:
>>> Common
>>>   CorebootPayloadPkg
>>>   DuetPkg
>>>   EmulatorPkg
>>>   Nt32Pkg
>>>   OvmfPkg
>>
>> So, I would like to propose a semi-tedious change here:
>> Merging the ArmVirtPkg and OvmfPkg directories.
>> ArmVirtPkg already uses many components maintained in OvmfPkg, and
>> ArmVirtPkg packages fulfills _exactly_ the same function, only for a
>> different architecture. We've seen a fair bit of confusion around the
>> separation of these two, both from Linux distribution packagers and
>> developers of virtualization tools and frameworks.
>>
>> My proposal is not for a heavy-handed merge of the source code, but
>> simply for moving all of the sources and platform configuration files
>> into the same package, adding the ARM targets to build.sh, and so on.
>>
> 
> I agree. While I'm not certain about it, I think we can reasonably
> manage having all virt related platforms under a single OVMF area.
> 
> I would rather think of these platforms similar to qemu ... ovmf-ia32,
> ovmf-x64, ovmf-arm, ovmf-riscv, etc... In the case of QEMU, I think we
> should have a goal to support the intersection of UEFI architectures,
> and systems supported by QEMU.
> 
> Similarly, I'd also like to try to continue to support qemu/kvm and
> Xen in the same platform area as long as it is possible. I wouldn't
> want to rule out trying to support other VMMs as well if they can mold
> reasonably into the current OVMF modules.
> 
> Laszlo has two (reasonable) concerns. First, how to assign owners?
> Today we only have 1 or 2 people per package. That doesn't work well
> if we have 5 CPU architectures in a single OVMF area of the tree.
> 
> My thought is that we should change our Maintainers.txt process as
> needed. I think I mentioned the idea of co-maintainers. These would be
> contributors that can review and recommend patches for an area of the
> tree. They wouldn't have commit access, but if they give a Reviewed-by
> for the area that they co-maintain, then any committer can proceed to
> commit the change. They might also prep branches of reviewed patches
> for committers to more easily fetch and push.
> 
> It almost seems like we need 'architecture' maintainers as well. Maybe
> 1 person per CPU architecture that can review and commit things
> anywhere in the tree that clearly affects only that architecture.
> 
> Laszlo is also concerned about the hassle of making changes to all the
> OVMF platforms at once.
> 
> For example, I think Laszlo cited the BDS update. Once again, it is a
> reasonable concern, but with today's separation into distinct areas of
> the tree, we are just 'forking' the code in several places. I think we
> can also do similar 'forking' under the OVMF area of the tree as
> needed.
> 
> At the same time, I like the idea of trying to force all the platforms
> to use common modules and to adopt new things together. Ideally it'd
> get all the platforms moved forward faster together. I think Laszlo
> might argue (convincingly) that it could also slow down changes to all
> the virt platforms by forcing all the pieces to be moved in
> lock-step...

I don't want to hold back progress, so if you guys can work out a
reasonably careful methodology / tree structure for this, with a more
finely grained Maintainers.txt, I'll be fine. (I hope :))

Leif recommended "efi-virt" elsewhere, as an arch-less / catch-all name.
I think I prefer it a bit over ovmf-*: in case ovmf- is
mentioned, the idea is clear, but if you just want to say "guest UEFI",
without mentioning the guest arch, "ovmf" would be a bit misleading, due
to OVMF's historical correspondence to x86.

Anyway naming is always a controversial topic :) so I won't push hard
for any of the options.

Thanks
Laszlo

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

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

[Jordan Justen]

On 2016-06-26 08:44:04, Leif Lindholm wrote:
> 
> On Fri, Jun 17, 2016 at 10:51:47PM +, Kinney, Michael D wrote:
> > Common
> >   CorebootPayloadPkg
> >   DuetPkg
> >   EmulatorPkg
> >   Nt32Pkg
> >   OvmfPkg
> 
> So, I would like to propose a semi-tedious change here:
> Merging the ArmVirtPkg and OvmfPkg directories.
> ArmVirtPkg already uses many components maintained in OvmfPkg, and
> ArmVirtPkg packages fulfills _exactly_ the same function, only for a
> different architecture. We've seen a fair bit of confusion around the
> separation of these two, both from Linux distribution packagers and
> developers of virtualization tools and frameworks.
> 
> My proposal is not for a heavy-handed merge of the source code, but
> simply for moving all of the sources and platform configuration files
> into the same package, adding the ARM targets to build.sh, and so on.
> 

I agree. While I'm not certain about it, I think we can reasonably
manage having all virt related platforms under a single OVMF area.

I would rather think of these platforms similar to qemu ... ovmf-ia32,
ovmf-x64, ovmf-arm, ovmf-riscv, etc... In the case of QEMU, I think we
should have a goal to support the intersection of UEFI architectures,
and systems supported by QEMU.

Similarly, I'd also like to try to continue to support qemu/kvm and
Xen in the same platform area as long as it is possible. I wouldn't
want to rule out trying to support other VMMs as well if they can mold
reasonably into the current OVMF modules.

Laszlo has two (reasonable) concerns. First, how to assign owners?
Today we only have 1 or 2 people per package. That doesn't work well
if we have 5 CPU architectures in a single OVMF area of the tree.

My thought is that we should change our Maintainers.txt process as
needed. I think I mentioned the idea of co-maintainers. These would be
contributors that can review and recommend patches for an area of the
tree. They wouldn't have commit access, but if they give a Reviewed-by
for the area that they co-maintain, then any committer can proceed to
commit the change. They might also prep branches of reviewed patches
for committers to more easily fetch and push.

It almost seems like we need 'architecture' maintainers as well. Maybe
1 person per CPU architecture that can review and commit things
anywhere in the tree that clearly affects only that architecture.

Laszlo is also concerned about the hassle of making changes to all the
OVMF platforms at once.

For example, I think Laszlo cited the BDS update. Once again, it is a
reasonable concern, but with today's separation into distinct areas of
the tree, we are just 'forking' the code in several places. I think we
can also do similar 'forking' under the OVMF area of the tree as
needed.

At the same time, I like the idea of trying to force all the platforms
to use common modules and to adopt new things together. Ideally it'd
get all the platforms moved forward faster together. I think Laszlo
might argue (convincingly) that it could also slow down changes to all
the virt platforms by forcing all the pieces to be moved in
lock-step...

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

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

[Leif Lindholm]

On Mon, Jun 27, 2016 at 03:50:02PM +0100, Ryan Harkin wrote:
> >>   Silicon
> >> Arm
> >>   ArmPkg
> >
> > Much of ArmPkg should probably move across into UefiCpuPkg and
> > MdeModulePkg over time, but this is probably the best thing to do for
> > the restructuring.
> >
> >>   ArmJunoPkg
> >>   ArmVExpressPkg
> >
> > For most of these ARM ltd. platforms, the Silicon is not usefully a
> > separate component (it's early access Silicon designed for a specific
> > development board). So I would lean towards moving all of these to
> > Platforms.
> >
> 
> I agree.  I was just looking at the list and thought, "Those are two
> directories I was supposed to have moved to the OpenPlatformPkg tree
> long before now".

:)

> Perhaps I should just migrate them?  First, patches to add them to
> OpenPlaformPkg, 2nd a patches to remove them from EDK2.  No other
> changes.

Well, but here's the twist: apart from this proposal, there is the
other one about upstream platform support in Tianocore:
http://thread.gmane.org/gmane.comp.bios.edk2.devel/11624/

Once that gets finalised, most of the original reasons behind creating
OpenPlatformPkg goes away. So while it would currently make a lot of
sense to move that code into OpenPlatformPkg, that would mean it would
need to move at least once more in the future.

Regards,

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

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

[Ryan Harkin]

On 26 June 2016 at 16:44, Leif Lindholm  wrote:
> So, I managed to miss this thread for the longest time ... sorry about
> the late comments.
>
> On Fri, Jun 17, 2016 at 10:51:47PM +, Kinney, Michael D wrote:
>> Hello,
>>
>> Please review this one.  I missed a few updates to the dir changes
>> in edk2/master near the bottom.
>>
>> I have looked through all the feedback from the mail threads below
>> and updated this RFC to V3.
>>
>>   http://thread.gmane.org/gmane.comp.bios.edk2.devel/12364
>>   http://thread.gmane.org/gmane.comp.bios.edk2.devel/12754
>>
>> 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.
>>
>> 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_V3
>>
>> ==
>>
>> Updates in V3:
>>
>> ==
>>
>> * IntelFspPkg   -> Silicon/Intel
>> * IntelFspWrapperPkg-> Silicon/Intel
>> * IntelFsp2Pkg  -> Silicon/Intel
>> * IntelFsp2WrapperPkg   -> Silicon/Intel
>> * CorebootModulePkg -> Driver
>> * EmulatorPkg   -> Platform/Common
>> * Nt32Pkg   -> Platform/Common
>>Merge into EmulatorPkg in future
>> * UnixPkg   -> Deprecated
>>Next step is a request to delete
>> * BeagleBoardPkg-> Platform/BeagleBoard
>> * Omap35xxPkg   -> Silicon/TexasInstruments
>> * IntelSiliconPkg   -> Silicon/Intel
>>
>> ==
>>
>>
>>
>> ==
>>
>> Updates 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
>>
>> ==
>>
>>
>>
>> 
>>
>> # 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 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
>>
>> # Top Level Directory Structure (Listed Alphabetically)
>>
>> ```
>>
>> edk2
>>   Application Applications and application support libraries
>>   BaseTools   EDK II build tools/scripts
>>   ConfEDK II build configuration files
>>   CorePlatform agnostic packages for core FW services
>>   Deprecated  Packages that may be removed from edk2/master
>>   Driver  EDK II Drivers (no platform assumptions)
>> Non-Vendor specific EDK II drivers
>> Non-Vendor specific EDK II drivers
>> . . .
>> VendorVendor specific EDK II drivers
>>   
>>   
>
> Following on to the previous discussions, I still like the idea of
> separate platform (PEI) drivers and UEFI drivers directories. The
> former could be the Vendor portion.
> However, I also agree with Jordan that for UEFI drivers, the
> Linux-style functional organisation makes more sense. (You are more
> likely to want maintainers/reviewers to pay attention to all devices
> of one type rather than all devices from one manufacturer.)
>
>>   PlatformPlatforms used to validate edk2/master features
>> Arm   ARM specific platform packages
>> BeagleBoard   Beagle Board specific platform packages
>
> If this refers to BeagleBoard as in BeagleBoard.org, as