Re: [Qemu-devel] [Qemu-stable] [SeaBIOS] problems with freeBSD

[Gerd Hoffmann <kraxel@redhat.com>]

  Hi,

>> Would qemu consider using those blobs rather than different developers
>> using their distro toolchain to build up a random commit ID. I say
>> random only because often qemu releases ship with a non-release
>> seabios.

It happened (well, the snapshot thing).  But that isn't our preferred
model, it was just bad release cycle coordination and we'll try to avoid
doing it again.  There is reason why we have a 1.7.2 stable branch now.

The binary blobs are just a convenience thing because rebuilding the
firmware might not be that easy.  Not so much for virtualization where
host + firmware are the same arch.  But for emulation, where you need
the -- say -- ppc slof on a x86 machine, and the binaries shipped allow
people to get started without having to install (or compile) a cross
compiler first.

It is certainly not required to use blobs shipped.  In fact the release
tarballs include all the firmware submodules, so you can build the
firmware yourself if you want.  I've created roms/Makefile so you can
easily rebuild the (x86) firmware.  seabios is there, vgabios is there,
patches for ipxe are in flight.

> Just a note, or an "alternative opinion", so to say.  In Debian, we have
> a social contract which, among other things, ensures that the binaries
> you, as a user, get, comes with source which you can modify on the
> system you installed.  This requires, for example, that all binaries
> shipped are actually built from the corresponding source, and that
> no blobs from whatever other sources are used, ever.

That is perfectly fine.  How to you handle ppc firmware for x86 hosts
btw?  Build on ppc buildhost and ship as noarch package?  Or do you do
cross compiler builds, so that users can patch+rebuild it on their x86
host too?

> We don't even ship any upstream blobs in the debian qemu _source_
> package: we repack upstream qemu.tar.gz by removing these blobs.

That's a bit over the top for my taste as the release tarballs include
both source and blobs.  Although it might be the debian release is just
a bit too old for that, not fully sure with which release anthony
started to include the firmware submodules, might be it was after 1.1

cheers,
  Gerd