qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andreas Färber
Subject: Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU
Date: Tue, 03 Jan 2012 15:51:01 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0

Am 03.01.2012 14:42, schrieb Anthony Liguori:
> On 12/30/2011 09:43 AM, Andreas Färber wrote:
>> Am 29.12.2011 23:30, schrieb Anthony Liguori:
>>> 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.
> 
> Let's not speculate here..  There's already an existence proof that this
> approach works for most of the targets we support (Aboriginal Linux).
> 
>> 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.
> 
> Yes, but this just becomes the exception to prove the rule.

That depends. The way I understood you (and that I would like to get
clarified on the call) is that you wanted to require qemu-test test
cases for patches. That would require it to work for everything without
exception.

If however you just want this as an optional "I am more confident of my
changes if they work with qemu-test on x86, ppc, myfavorite", sort of an
alternative to downloading test images from qemu.org and running them
manually, then of course it doesn't really matter if target xyz or
feature foo cannot be tested in the same automated manner.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]