Re: [Qemu-devel] AVMF & OVMF blobs in QEMU tree???

[Alex Bennée]

Gerd Hoffmann <address@hidden> writes:

> On Mon, 2017-08-07 at 18:51 +0200, Laszlo Ersek wrote:
>> On 08/07/17 16:40, Peter Maydell wrote:
>> > On 7 August 2017 at 15:31, Igor Mammedov <address@hidden>
>> > wrote:
>> > > As I recall there were issues with FAT driver licensing in edk2,
>> > > but I've heard there were some changes in that regard.
>> > >
>> > > Is there any other reasons why we are not putting subj.
>> > > in QEMU tree like we do with SeaBIOS and other roms?
>> >
>> > I suspect the primary answer is "nobody who's willing to
>> > maintain, test and update the resulting binary blobs has
>> > stepped forward to say they want to do so" :-)
>> >
>> > (I think that shipping them in the QEMU tree would be
>> > nice but is principally a convenience for our direct
>> > users, since distros are going to want to build their
>> > own ROM blobs from source anyway.)
>>
>> I agree that OVMF and ArmVirtQemu firmware binaries (and matching
>> varstore templates, likely compressed) should be bundled with QEMU.
>> There are no license-related reasons left that would prevent this.
>>
>> Please let us discuss this when Gerd returns from vacation. (CC'ing
>> Gerd.)
>
> slighly oldish wip branch:
> https://www.kraxel.org/cgit/qemu/log/?h=work/edk2
>
> Related question (as the edk2 blobs are pretty big):  Do we want commit
> this to the qemu repo directly?   Or should we create a qemu-firmware
> repo for the precompiled blobs and hook it up as submodule?

How big? Things like github tend to get picky with blobs over 50Mb and
git isn't really set-up for large binary bits hence things like git-lfs.
Unfortunately there seems to be multiple solutions to the blobs in git
problem.

We should also take some care to reproducibility so they can be updated
by someone other than the original author.

>
> cheers,
>   Gerd


--
Alex Bennée