[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH for-1.6? v2 00/21] qtest: Test all targets
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] [PATCH for-1.6? v2 00/21] qtest: Test all targets |
Date: |
Tue, 06 Aug 2013 11:04:57 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 |
Am 06.08.2013 10:39, schrieb Markus Armbruster:
> Andreas Färber <address@hidden> writes:
>
>> Hello Anthony/Aurélien,
>>
>> This series extends test coverage to all 16 targets.
>> For now it tests that QOM type changes do not lead to QOM cast assertions.
>>
>> v2 extends it to cover virtually all machines (except Xen and pc*-x.y).
>> Where an fprintf() is touched, use error_report() instead.
>
> Yes, we need such a smoke test for all targets.
>
> I toyed with it myself, but I haven't been able to go beyond the crude
> hackery we discussed about a year ago:
> https://lists.nongnu.org/archive/html/qemu-devel/2012-08/msg01197.html
>
> The problem is that many targets have mandatory options (fun oxymoron),
> such as -kernel or -pflash.
>
> If I understand your approach correctly, you solve it by making these
> mandatory options optional when qtest_enabled().
>
> My idea was to create suitable dummy images, so we can provide the
> mandatory options. Guest won't be happy, but that's fine, as this smoke
> test doesn't want to run any guest code.
Peter rejected having a U-Boot per machine. And from my own arm porting
experiences that would mean having close to one source of U-Boot per
machine since upstreaming works really badly in the embedded world. :(
Anthony's JeOS project doesn't seem to be actively worked on any more,
at least my patch unbreaking .gitmodules never seemed to get
incorporated, and I ran into the issue of openrisc and unicore32 (the
targets where we didn't have any test images at the time) not having
upstream binutils/gcc support yet. I really hate to say: I did predict
one source of binutils/gcc/uClibc/kernel/etc. was not going to be
sufficient for all targets...
> I like my idea better, because with it we can run unmodified standard
> code. No testing of qtest_enabled().
>
> However, you've got patches, and I haven't, and that means I like your
> *patches* infinitely more than mine ;)
Thanks. I'm thinking "qtest" is easy to grep for in machines and most
should be easy to revert/replace once we have a better plan.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg