qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] Future goals for autotest and virtualization test


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC] Future goals for autotest and virtualization tests
Date: Fri, 09 Mar 2012 15:30:18 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1

Il 09/03/2012 15:01, Anthony Liguori ha scritto:
>> How do you handle out-of-tree patches with submodules (as is the case
>> when working on new code)?
> 
> It's very easy to update .gitmodules to point to a different tree on
> your local system and then update the ref to a local commit.
> 
> So from a development perspective, it's simple.  The harder question is
> what to do about qemu-test HEAD on qemu.org

Yep.  So you would commit patches to qemu.git with some kind of IOU for
tests, that will be committed as soon as kernel support hits the mainline?

>> You want to require tests in order to commit to qemu, but this (for
>> tests where using qtest is not feasible for any reason) requires all
>> drivers to be upstream and accessible to qemu-jeos.
> 
> We're really just talking about virtio here, no?  Maybe we can convince
> Rusty to have a proper virtio-next.git...
> 
> I think this ends up being outside the scope of qemu-test.  Perfect is
> the enemy of good here.

No, this ends up being outside the scope of Anthony, who only cares
about testing KVM/x86.  We add one virtio device every couple years,
while new ARM boards are added every couple months.  It kind of works
because a large part of the QEMU development community is testing on
KVM/x86, but not entirely.

It is not a problem. of course: you're human, you're one person and one
would need a dozen to set up everything properly.  OTOH, it's too easy
to dismiss buildroot when you are catering to a much smaller objective.
The complete objective would have a much bigger overlap with
buildroot's, and likely the design would too.

Paolo



reply via email to

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