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). (2) Sharing more code between modules that aren't inherently architecture-independent (and virtualization platform-independent) is risky. 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). 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). 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.) 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. In fact, these stakes would be much better reflected if Ard *too* were a Maintainer for OvmfPkg. Thanks Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
