07.03.2013 10:12, Doug Goldstein wrote:
On Wed, Mar 6, 2013 at 7:58 PM, Peter Stuge peter@stuge.se wrote:
Yeah, it is very common. Lots of distributions patch their toolchains such that they don't compile firmware code correctly.
Firmware isn't a common target, so I understand that it happens.
For coreboot we recommend to build a vanilla toolchain using known good versions. We also have a script to do that. (The script is at util/crossgcc/buildgcc in the coreboot repo.)
[]
Not sure if you or Kevin builds the coreboot images at http://code.coreboot.org/p/seabios/downloads/, but would you guys consider building point release as well (e.g. 1.7.2.1), if yes then my next question...
The rest of the ML,
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.
In this past there's been other issues related to seabios + qemu, that I've solved in Gentoo by simply using the coreboot seabios images after some troubleshooting help from Peter. Similarly our Ubuntu OpenStack machines at work had quirks resolved by dropping the coreboot seabios images on them.
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.
We don't even ship any upstream blobs in the debian qemu _source_ package: we repack upstream qemu.tar.gz by removing these blobs.
So from this PoV, it'd be better if upstream didn't ship any blobs at all, -- we wont need to repack the upstream .tar.gz ;)
FWIW, prpbably we were lucky so far: we had almost no issues with (mis)compiling of various ROM codes (bochsbios, seabios, vgabios, pxe roms, various sparc/ppc firmware etc) using toolchains provided by Debian.
Thanks,
/mjt
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
07.03.2013 15:56, Gerd Hoffmann wrote:
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?
"Foreign" firmware handling is an unsolved issue. Yes, basically, it is built on the corresponding build machine (eg, openbios-ppc is built on a ppc machine) and shipped as "noarch" package. The same is for X86 seabios/vgabios/etc stuff actually.
So technically this is a violation in some way. However, that same ppc firmware actually can be rebuilt in a (qemu) virtual machine with the same debian release installed.
That's why I say it is basically unsolved issue -- the "solution" isn't actuall a solution but a workaround instead.
For added "fun", currently we ship optionroms from qemu in seabios source package, exactly because of this reason - seabios is what gets built on x86 only and is distributed on as "noarch" binary, while qemu is built on all architectures.
And for another fun, we've several broken qemu architectures in Debian at the moment -- s390 and ppc64 are missing firmwares exactly because of the difficulties building them, despite the fact they're shipping in upstream qemu tarball.
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.
Yes this is a bit extremistic, so to say. But this is the same base principle of Debian: we should ensure and demonstrate it all is buildable. Just mere presence of a blob in a tarball is already suspicious :)
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
Nope, qemu started including sources before that. But it doesn't matter really, it is just the way how debian works, nothing to do with qemu really. Especially since most of these submodules are already packaged in Debian separately (be it because the qemu needs or due to other means).
Thanks,
/mjt
On 7 March 2013 19:56, Gerd Hoffmann kraxel@redhat.com wrote:
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.
qemu-linaro's source tarballs (and indeed git tree) drops the blobs as well. I didn't want to have to deal with the issues of making sure the sources were present and matched the blobs.
In general having blobs in our allegedly source tarball is pretty ugly. Either it's a source release or it isn't. We can do a release-of-blobs tarball too if we want, but it doesn't need to be in the source tarball and it doesn't need to be in git either IMHO.
-- PMM
-
Gerd Hoffmann -
Michael Tokarev -
Peter Maydell