03.31.09
firmwares for qemu
Firmwares, as usual, are a very tricky thing.
A while ago, while reviewing patches for enabling ia64 on our kvm spec file, we came across a very sad conclusion: We were violating a bunch of Fedora policies in our kvm package.
Of course we did not mean it, but still: we were.
It happened with binary blobs for firmwares. We did have the source code for all of them, but we were not building it, since they were distributed upstream in binary form only. At first I thought it was a non issue:
qemu distributed the binaries for the various bioses, but kvm built it. Specially because we had a heavily modified version of the x86 bios. But then I was proven wrong. Although the bios was in fact okay, the pxe roms for ethernet cards were distributed in binary form only. And our package were just passing them ahead.
It seems a quick fix. Just go and build. But it turns out to be not that easy. Let’s see why:
- A qemu target for a platform, say x86, runs natively on its host, be it a mips, ppc, or any other. But the firmware is not part of the emulator. It runs on the emulator, as software for the target platform.
- As such, it needs to be compiled for the said platform. Here, you either have a cross compiler set, or you compile it natively on the target platform
- Fedora does not have a cross compiler environment set up
- We only package kvm for i386 and x86_64. Given some luck, we can compile i386 code on x86_64 with the right compiler flags. But last time I checked, we were Fedora, and we like doing things right. This would fix the issue for kvm, but leave qemu, that uses the same binaries, exposed to the same liability problem
BTW, this one of (not the) motivators for having the package merge done early.
After a lot of thinking and consideration, we decided for the following:
- We created a package for etherboot. Nice side effect is that one can now have roms for any etherboot-supported card. Be it for writting a new emulator, to flash it somewhere, whatever. It is just there.
- Build the package as a scratch build on i386
- The resulting binaries of this build are put on a .tar.bz2 file, that is then listed as Source1
- For platforms other than i386, we just unpack this binaries
This is quite a hack, but used to be the best we could do. The situation actually got worse when we finally decided to merge the packages. We would basically have to have the same issue for the x86 bios, x86 vgabios, ppc firmwares, etc.
Hopefully, when I was already prepared to jump out of the window, the blue sky opened, and a voice talked to me, filling my heart with joy. Koji would support .noarch subpackages.
Usually, noarch packages are not built. It makes sense in the normal scenario. But noarch packages would never work for us. Now, what we do is:
- Mark the package as BuildArch: i386. ExcludeArch does not work, since it would then rip off the noarch subpackage for the other repos as well
- Create a noarch subpackage, containing the binary only files. This will then reach all repositories.
- For trickier packages, like openbios - it does not have a single build arch, but rather has to be built on ppc, sparc32 and sparc64, I’m enclosing the build and the creation of the noarch subpackage by ifarch directives.
We are not 100 % on that yet. But I do believe we’re in a much better shape wrt the qemu firmwares issues in Fedora now.
Popularity: 11% [?]
