[Top][All Lists]

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

Re: [Qemu-block] [PATCH 0/6] QTests: use Python to run complex tests

From: Paolo Bonzini
Subject: Re: [Qemu-block] [PATCH 0/6] QTests: use Python to run complex tests
Date: Thu, 14 Dec 2017 12:35:46 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

On 14/12/2017 10:39, Stefan Hajnoczi wrote:
>>             # verify Card ID
>>             data = self.bus.do_cmd(ALL_SEND_CID)
>>             oid, pnm, psn = struct.unpack(">x2s5sxLxxx", data)
>>             self.assertEqual(oid, "XY") # QEMU default
>>             self.assertEqual(pnm, "QEMU!") # QEMU default
>>             self.assertEqual(psn, 0xdeadbeef) # QEMU default
> Device qtests are better done in C than Python.  Python is not good at
> binary I/O and porting this to Python 3 will be extra work later (Python
> 2 is set for End-of-Life in 2020, see https://pythonclock.org/).
> More importantly, we already have libqos in C with a guest memory
> allocator, PCI, and virtio support.  Fragmenting the small amount effort
> that goes into device testing will delay libqos reaching critical mass.
> Critical mass is where libqos provides all the infrastructure you need
> to set up a device and focus on your actual test instead of machine,
> bus, or device initialization.  Starting a Python device testing effort
> will just lead to duplication and 2 underdeveloped device testing
> frameworks.

I agree that fragmentation is bad.  However, libqos is small (about 4k
lines of code, maybe 3k in Python).

I also agree that any qtest written in Python should be written in
Python 3 from the beginning (in fact we should consider dropping Python
2.x support in 2.12).  Doing so should not make binary I/O much
different than C.

From my point of view, the main advantage of Python is the reflection
mechanisms.  Those would make it possible to automatically discover the
set of runnable tests; for example, based on:

- two machine descriptions (including malloc) for ARM -M virt and x86 -M q35

- a driver for the generic PCIe host bridge

- a driver for virtio-pci

- a driver for virtio-scsi

- a set of SCSI tests

... it should be possible to run the same tests as either ARM or x86
qtests.  This would be a very different framework compared to the C libqos.



> Is there a specific reason why adding SD Card support to libqos is not
> possible in C?

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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