Re: [Qemu-devel] [PATCH 00/10] bundle edk2 platform firmware with QEMU

[Philippe Mathieu-Daudé]

On 3/12/19 4:33 PM, Laszlo Ersek wrote:
> On 03/10/19 12:21, Philippe Mathieu-Daudé wrote:
>> On 3/10/19 4:56 AM, Michael S. Tsirkin wrote:
>>> On Sat, Mar 09, 2019 at 01:48:16AM +0100, Laszlo Ersek wrote:
>>>> Repo:   https://github.com/lersek/qemu.git
>>>> Branch: edk2_build
>>>>
>>>> This series advances the roms/edk2 submodule to the "edk2-stable201903"
>>>> release, and builds and captures platform firmware binaries from that
>>>> release. At this point they are meant to be used by both end-users and
>>>> by Igor's ACPI unit tests in qtest ("make check").
>>>>
>>>> Previous discussion:
>>>>
>>>>   [Qemu-devel] bundling edk2 platform firmware images with QEMU
>>>>   http://mid.mail-archive.com/address@hidden
>>>>   https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02601.html
>>
>> There David raised a concern about "[adding] ~206 MB of binaries to the
>> pc-bios directory".
> 
> (I think the concern was voiced by Dan first.)
> 
>> I'm also worried.
> 
> I'm not. The actual data size, both to transfer (push/pull) and to store
> in the .git subdirectory, is ~9MB. (As I explained earlier.)
> 
> git-checkout *could* in theory eat more space, but, in my testing, it
> doesn't; for me, git-checkout punches holes in the checked-out files.
> Please see the earlier discussion for that reference too. (Note: I'm on
> ext4, so nothing enterprisey like xfs.)
> 
>> GitHub kindly suggest to use git-lfs.
> 
> Just ignore that -- not because it's another dependency, but because
> external storage for these blobs is actually not required.
> 
>> It is an extra dependency I'd
>> rather strongly avoid (because we support a wide range of host OS, each
>> using a wide types of filesystems).
>>
>> What about storing those binaries on a file server (http/ftp) altogether
>> with a file containing its hashed digest (SHA1/SHA256)? Then we already
>> have all the required tools to fetch and verify those blob roms with the
>> build system.
>> Or we could store the hashes in the QEMU repository too.
> 
> Let's not implement "fedpkg sources" within upstream QEMU, unless we
> really must.
> 
>>
>>>> Note that the series was formatted with "--no-binary" (affecting patch
>>>> #8), therefore it cannot be applied with "git-am". See the remote
>>>> repo/branch reference near the top instead.
>>>>
>>>> Thanks,
>>>> Laszlo
>>>
>>> High time IMO.
>>
>> :)
>>
>>> Reviewed-by: Michael S. Tsirkin <address@hidden>
>>>
>>> Laszlo I suggest you add an entry to MAINTAINERS
>>> and start doing pull requests.
> 
> I'm glad to do that (in the hope that updates will be mostly painless,
> regarding the build scaffolding).
> 
>>
>> This is the entry I added here:
>> https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02967.html
> 
> Hmm. That hunk is insufficient (it doesn't cover the files being added
> here), but if I add another hunk myself, then we'll have redundancy.
> 
> In other words, this is a conflict. How should we resolve it? Should I
> add a separate patch at the end, and let Michael drop it or resolve the
> conflict, dependent on the order in which the series end up being merged?

Likely yours first.

These two lines should match your series:

F: pc-bios/descriptors/*edk2*
F: pc-bios/*edk2*

>>
>>>
>>> Peter, what do you say? OK with you?
>>
>> Since this series doesn't change the QEMU binaries built, it looks OK to
>> me to merge it past soft freeze (as we do we tests/CI), this way it get
>> merged with the final EDK2 release tag.
>> Else we can merge it next week, and update the EDK2 submodule tag
>> previous QEMU release.
> 
> I don't understand this paragraph -- the edk2 submodule commit reference
> is already the final one I have targeted for this work, namely
> "edk2-stable201903". (I had worried edk2 would suffer a delay in
> publishing the tag, but ultimately the community managed it just in time.)

"If edk2-stable201903 tag were delayed, this series is still OK to get
merged for the hard freeze (next tuesday)."

> Thanks
> Laszlo