On 09/09/15 18:34, Ian Campbell wrote: > On Wed, 2015-09-09 at 10:57 +0200, Laszlo Ersek wrote: >> On 08/10/15 18:24, Laszlo Ersek wrote: >>> Hi. >>> >>> Let's do an OVMF BoF at this year's KVM Forum too. >> >> Here's a preliminary task list > > Thanks for including xen-devel in this. Was anyone from the Xen community > present at the BoF (so far as you know)? Are there any minutes or anything > like that for those interested in the discussion and reasoning rather than > just the resulting action items?
Okay, second attempt at an answer. I *have* forgotten a great deal of the sentences that were uttered at the BoF, but I mostly remember why we wanted these things. :) So let me see if I can elaborate on these (after all you are interested in the reasoning in general, not just the discussions that I fail to recall in detail): >> , after some off-list discussion (I tried >> to incorporate comments): >> >> - create GPL'd fork called "ovmf" for expediting virt development >> (OvmfPkg, ArmVirtPkg) >> - maybe leverage the feature under >> <http://permalink.gmane.org/gmane.comp.bios.edk2.devel/941> for >> setting up a separate "tianocore/edk2-gpl" repo, for GPL'd >> contributions [Jordan] >> - repo separation by license could make things harder for packagers >> and QEMU bundling [Laszlo] So in this item (which, in the above form, is already obsolete) I managed to mix up three separate things. (But Jordan then went on and clarified those today.) (1) One thing is a virt-oriented fork of edk2, without explicit licensing-oriented goals. The main purpose of this fork would be to expedite virt development (OvmfPkg, ArmVirtPkg, and central packages on which the former two depend). It has sometimes occurred that an OVMF feature got tied up in inter-maintainer disagreement, or other non-technical reasons (lack of review capacity etc). This holds back virt development, plus it has the potential to force downstreams (let's be concrete: Red Hat at minimum) to carry some patches in downstream only. The fork would accelerate things here. We'd have a set of rules for committing to the fork (and the divergence would have to be rebased periodically, or alternatively edk2 patches would have to be merged into the fork, periodically). Considering this purpose (ie. expediting virt development) in isolation, the fork should stick with the original edk2 licenses. (2) The *ability* to provide the end user with free software (in the FSF's definition) or open source software (in the OSI's definition), which the current FAT driver is regrettably none of, is extremely important. Currently the only alternative that appears feasible is Peter Batard's UEFI port of GRUB's read-only FAT driver. That driver comes under the GPL, and therefore it ties into topic (3) below. However, note that if the in-tree FAT driver were liberated (= made Free or Open Source Software, for example by dropping the "Additional Terms" from its license, thereby rendering it 3-BSDL), then goal (2) would be immediately achieved, and it wouldn't tie into goal (3) below. (3) Accommodating drivers that contributors can (or are willing to) submit only under the GPL would be nice. For example there has been such a contribution from Ludovic Rousseau, a smart card reader protocol implementation (a port from Linux). Jordan's most recent suggestion was to actually keep GPL'd drivers within edk2, under "GplDriverPkg". This is being discussed on edk2-devel, so I'll move on. >> - document the rules / justification for "ovmf" (licensing >> conflicts, non-technical blockage on edk2 etc). >> - No new mailing list needed Okay, so the rules. They would go like (obviously they are up for discussion): - submit your stuff to edk2-devel as always - work with the reviewers / maintainers - if you get demonstrably stuck, due to inter-maintainer deadlock (ie. you'd be fine implementing either maintainer's request, but their requirements *together* are unsatisfiable, because they conflict), the patches can be committed to the fork, subject to review *for* the fork - same if there's just no feedback for a patchset - same if the patches are blocked due to non-technical criticism - maybe the same if the technical feedback would require *disproportionate* effort (ie. cross-package refactorings), esp. involving client (=platform) packages that are not related to virt. We have to be careful with this one (it's not a blanket excuse, and arguments are bound to be somewhat subjective here), but such unjustified / overarching / disproportionate requirements can block the upstreaming of a feature (developed under a deadline) for good. Example: consider a refactoring that straddles DuetPkg or EmulatorPkg *and* MdeModulePkg, so that you can use a feature in OvmfPkg. You just turned a two week development effort into 6-8 weeks. No. You might not even have the environment to test DuetPkg. Etc. - Initial set of committers to this fork would be the current virt package maintainers (ArmVirtPkg, OvmfPkg). - Reviews should be done for the fork too, of course. But, the chance for inter-maintainer deadlock is much smaller. (Eg. if a virt-pkg maintainer "deadlocks" with a non-virt-pkg maintainer while reviewing a virt-related (or virt-serving!) patch, then as far as the "ovmf" repo is concerned, the virt-pkg maintainer's requirements automatically "win", and the patch submitter becomes capable of implementing the requirements, even if the implementation affects the non-virt-pkg maintainer's package.) >> - push RH's downstream-only patches to "ovmf", wherever that makes >> sense Some of those are downstream only due to problems listed above. Some other patches are admittedly not suitable for upstream. (They are not "secret"; anyone can see them in the SRPM.) >> - remove encumbered FAT driver See (2) >> - import Peter Batard's GPL r/o FAT driver port of GRUB's This is *one* alternative for solving (2), and it happens to tie into (3). (The optimal alternative would be relicensing the in-tree FAT driver, but that's not something that can be contributed.) >> - secure OpenSSL linking exception for the former from the copyright >> holders (Peter Batard, GRUB project) Further complication for (3). "Linking" GPL code together with OpenSSL licensed code is not trivial, I'm told. (The concept of "linking" might also be interesting for a firmware image.) I'm not a lawyer (obviously), so this item is here to keep the question on the radar. I'll note that if (2) was solved by relicensing the current FAT driver (and therefore (2) didn't tie into (3)), then (2) would become independent of this question as well, and this question would lose a lot of significance (similarly to (3)). >> - "ovmf" should be periodically rebased / should fetch+merge edk2 as >> master (arguments both for and against merging); distros should >> then track "ovmf" as their upstream, not edk2 Distros packaging OVMF and/or ArmVirtPkg should follow the fork, because some ("trapped") features would exist only there. >> - get OVMF into Fedora (as pkg) and QEMU (as bundled binary) (2) is both necessary and sufficient for this! >> - do OVMF releases, maybe in sync with QEMU's releases >> - we can probably build from known good revisions from git [Alex] Helps with error reporting and narrowing down regressions, before starting an actual bisection. >> - revive Q35 SATA driver work / poke Reza >> - Hannes and Gabriel have refreshed patches, but their versions differ A SATA driver for Q35 would be really nice, although both Linux and Windows guests can be installed without such a firmware driver (requiring virtio-containing initrd's / driver disks, respectively). AFAIR this work got bogged down in cross-module requirements too. ... I hope this helps. I'm sorry if the above ended up chaotic; I'm tired but I didn't want to leave it at "I don't remember". I do remember the reasons, if not the specific discussion. Corrections welcome, of course... Thanks Laszlo >> >> >> _______________________________________________ >> Xen-devel mailing list >> xen-de...@lists.xen.org >> http://lists.xen.org/xen-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
