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

[Paolo Bonzini <pbonzini@redhat.com>]

On 14/12/2017 17:05, Markus Armbruster wrote:
> Nir Soffer <nirsof@gmail.com> writes:
> 
>> On Thu, Dec 14, 2017 at 1:36 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>>> 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.
>>
>> Using python 3 will make it hard to develop and test qemu on RHEL/CentOS
>> which do not provide python 3 yet.
> 
> s/hard/slightly inconvenient/: Python 3 is available in EPEL.  

And also in software collections.  For 2.12 (as part of the above "drop
Python 2.x support" plan) my idea is to set up a virtual Python
environment as part of configure, so that you can just do

	scl enable rh-python36 ./configure
	make

if you don't want to use EPEL.

Paolo

>> Doing binary io in python 2 and 3 is the same, there is no need to use
>> python 3 for this. The only advantage is not having to backport code
>> later from 2 to 3.