Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

["Andreas Färber" <afaerber@suse.de>]

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