On Thu, Aug 17, 2017 at 01:47:59AM +0200, Laszlo Ersek wrote:
> On 08/17/17 00:37, Jordan Justen wrote:
> > On 2017-08-16 12:23:49, Leif Lindholm wrote:
>
> [snip]
>
> >> - the value proposition
> >> for Linaro is that having maintainer parity ArmVirtPkg/OvmfPkg
> >> simplifies the task of maintaining feature parity between the two.
> >> (It is no secret that I would love to see them as a single package,
> >> making it easier to clean up the way EDK2-for-qemu gets packaged by
> >> Linux distributions.)
> >
> > I would also prefer to have OVMF support ARM and eventually RISC-V as
> > well. I don't think Laszlo feels as confident about this though.
>
> I have two concerns:
>
> (1) Reorganizing OvmfPkg for this would take an immense amount of time
> (with possible regressions).
Well, I'm the one who keeps pushing for it, so it'd be impolite of me
to suggest that someone else should have to deal with it.
> (2) Sharing more code between modules that aren't inherently
> architecture-independent (and virtualization platform-independent) is risky.
Let me start by clarifying what I would like to see:
- ArmVirtPkg and OvmfPkg merged into one package.
- Merging a lot of common items into shared .dsc.inc and .fdf.inc
across all platforms.
- ARM/AARCH64 platforms added to build.sh/create-release.py.
- End.
> By "sharing more code", I mean extracting further library classes and
> then unifying originally separate drivers. I also mean extracting common
> files from separate library instances, and then unifying the lib
> instances in a common directory, with multiple INF files, or with
> arch-dependent sections in the one resultant INF file. Another method is
> to control the same set of drivers / library instances differently, via
> dynamic PCDs.
>
> While all this is great for code de-duplication, the chance of
> regressions skyrockets if the code de-dup is not matched by a similar
> overlap in maintenance (that is, review and testing).
All of the above, I consider a lot less important to deal with short
(or even medium) term. Where and when things make sense to break out,
I'm sure you will do so without prompting. What I want to do is remove
the current structural barrier we have.
> Personally I use QEMU/KVM (and occasionally QEMU/TCG) on x86 and
> aarch64. I don't use 32-bit ARM (even guests, on aarch64 hosts), or any
> kind of Xen. I've never seen RISC-V hardware (and probably won't --
> nested TCG with QEMU doesn't count).
Let's be honest here. Yes, there is a risk of 32-bit ARM and RISC-V
ending up poorly tested. That is also much less of an issue than ARM64
and X64. If that changes, absolutely, validation for those needs to be
seriously improved.
But frankly, at this stage, _not_ setting up some CI jobs running
LuvOS on all QEMU/TCG targets on a nightly basis is just down to
laziness. (That finger is pointing very strongly towards myself.)
QEMU/KVM would require a little bit more effort, but not tons.
> The best counter-indication for this kind of increased sharing is the
> *numerous* Xen-related regressions that have slipped through in the
> past, simply because none of the OvmfPkg maintainers use Xen. (And the
> Xen project seems to be unwilling or unable to delegate an official
> reviewer or co-maintainer for the Xen-related code in OvmfPkg, despite
> my repeated requests.) This has happened under ArmVirtPkg too (I recall
> ACPI vs. DT related changes -- surprisingly, even *that* selection is
> specific to the virtualization platform.)
Sure, but the Xen situation is completely different, since (as you
say) there is no co-maintainer looking after that.
This also means it would be completely valid to break out the Xen
support into a separate package with S: Orphan.
> The bottleneck in open source development is not writing code, it is
> reviewing and regression-testing code. (This is painfully obvious in
> Linux kernel and QEMU development, but the same can be experienced on
> edk2-devel as well.) Therefore OvmfPkg's structure should match the
> distribution of OvmfPkg's active stake-holders over architectures and
> virtualization platforms.
>
> IMO the current code sharing between OvmfPkg and ArmVirtPkg, while
> certainly not 100% polished, is workable -- meaning that it mostly
> corresponds to the stakes that ArmVirtPkg and OvmfPkg maintainers and
> long-term contributors hold in the shared modules.
Sure. And I am not suggesting that the _code_ sharing needs to change
at this point. I just feel there is more alignment between
ArmVirtPkg/Qemu and OvmfPkg/Qemu than there is between OvmfPkg/Qemu
and OvmfPkg/Xen (or indeed ArmVirtPkg/Qemu and ArmVirtPkg/Xen).
> In fact, these stakes would be much better reflected if Ard *too* were a
> Maintainer for OvmfPkg.
I'm glad we agree :)
/
Leif
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
