Am 29.12.2011 23:30, schrieb Anthony Liguori: > On 12/29/2011 04:10 PM, Peter Maydell wrote: >> How does your framework deal with non-x86 targets? > > http://git.qemu.org/qemu-jeos.git > > I've already got ppc32 support working. Adding a new arch is just a > matter of adding a kernel config and uClibc config to configs/ > >> Finding and >> installing a working crosscompiler can be painful, especially if >> you wanted to crosscompile userspace rather than just the kernel... > > I spent a couple days researching what to do here and ended up settling on: > > 1) build binutils for desired target > > 2) build GCC using (1) as a cross compiler. This is a limited form of > GCC (no thread support) targeted as uClibc > > 3) build kernel using (2) and installer headers into our new sysroot > > 4) build uClibc using (2) and (3) > > 5) build busybox using (2) and (4) > > The whole process takes about 30 minutes on my laptop using -j1 which > isn't all that bad. It's certainly faster than doing a distro install > with TCG :-) > > qemu-jeos.git contains git submodules for binutils, GCC, linux, uClibc, > and busybox plus miscellaneous scripts needed to make a working initramfs.
"One ring to rule them all ... and in the darkness bind them"? ;) Seriously, what you describe may work for mainstream targets. But for new targets the trouble starts with 1) already: which binutils? The latest stable may not work for all architectures yet, so a generic submodule approach is doomed to fail. Will uClibc work for all targets? There's glibc, eglibc, newlib, ... Not all targets have a softmmu at this time: unicore32 (Fwiw this also means no testing outside Linux hosts.) There's no requirement that the Linux kernel must have been ported to a QEMU target yet or that it is still in mainline or that what is in mainline is complete enough for our testing. So, I'm fine if you come up with a cool testing framework, with or without Q in the name. Just please don't imply from testing two targets that this is a one-size-fits-all solution for all current and future targets. The qtest approach seems more promising in that regard. > Once we get more ARCHs working, I'll add a cronjob to qemu.org to build > weekly binary packages so that for most people, all you have to do is > grab an RPM/DEB with prebuilt binaries. I have a feeling OBS, Koji, etc. are more suited for this than trying to set up a build service of your own. Let's leave qrpm for April 1st. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg