qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/1] qemu-firmware repo


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 0/1] qemu-firmware repo
Date: Wed, 27 Sep 2017 13:34:12 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

On 27/09/2017 11:15, Daniel P. Berrange wrote:
> On Wed, Sep 27, 2017 at 09:19:22AM +0200, Paolo Bonzini wrote:
>> Are you planning to include only submodules, or also "QEMU-native"
>> firmware such as linuxboot, kvmvapic, s390-ccw, spapr-rtas, etc.?
> 
> The submodules make sense to split out because distro vendors buld them
> independently of QEMU, and would rather not have them in the tarballs,
> so they have a clearer path to license compliance and legal export
> certification.
> 
> The other bits of mention are all built normally as part of QEMU and
> not subject to these problems, so I don't see a benefit to splitting
> them out of QEMU.

They aren't rebuilt in general.  You end up with x86 builds of
qemu-system-x86 rebuilding linuxboot, ppc builds of qemu-system-ppc
rebuilding spapr-rtas, etc. (search configure for "roms=").  In fact,
QEMU has a special exception in Fedora just because these are too hard
to untangle.

So the advantage would be the ability to introduce better infrastructure
for cross compilation, without complicating further the QEMU build system.

> putting those bits in the qemu-firmware
> repo would re-introduce the problem we're trying to solve because
> distros would then need to get linuxboox, kvmvapi etc from a tarball
> of qemu-firmware which would once again include all the bits they
> don't want to have.

This is true.  We could distribute a qemu-firmware tarball with just the
QEMU-specific bits, and a qemu-firmware-all tarball with also those that
are built separately.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]