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: Cleber Rosa
Subject: Re: [Qemu-devel] [RFC] Future goals for autotest and virtualization tests
Date: Fri, 09 Mar 2012 09:40:05 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1

On 03/09/2012 09:04 AM, Anthony Liguori wrote:
On 03/09/2012 05:20 AM, Cleber Rosa wrote:
You're comparing developer-level tests with the existent QA-level
tests (much more complex).

Let's be specific then. Look at device-add.sh in qemu-test. It's 71LOC.
pci_hotplug.py in autotest is 204LOC.

pci_hotplug.py does much more than device-add.sh:

* tests both pci_add and device_add commands
* checks the monitor syntax for adding a new drive, that is, it works on HEAD
and on other versions (such as the ones in some RHEL releases);
* tests both nic and block hotplug
* for block, tests with both virtio and scsi
* also does device removal, both for pci_add and device_add syntaxes

Ok, but clearly, there's no magic in autotest that makes this sufficiently easier. It's just a matter of:

cmd=`named_choose command device_add pci_add`

if test $cmd = "device_add"; then
  qmp device_add --driver=virtio-blk-pci --drive=hd0
else
  hmp pci_add auto virtio-blk-pci,drive=hd0
fi

It's not there today because pci_add is deprecated. There assertion was that autotest makes it easier to write tests. How does it make it easier to write pci_hotplug?


Sure. I agree that it's fair from QEMU's PoV alone to forget about legacy things such as pci_add.

On this particular example, the one thing that strikes me the most is that (kvm-)autotest allows either a very static test run (as device_add.sh does), or a very configurable test run (as pci_hotplug.py does and QE needs).

I believe that with little compromises (required by any kind of collaboration) we can have the best tests/tools/libraries/framework/whatever by combining these similar code bases.

Again, we're willing to work and try to make that happen, but IMHO there must be a more open attitude here.

Cheers,
CR.

Regards,

Anthony Liguori




reply via email to

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