Re: [Xen-devel] OVMF BoF @ KVM Forum 2015

[Laszlo Ersek <lersek@xxxxxxxxxx>]

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-devel@xxxxxxxxxxxxx
>> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel