qemu-block
[Top][All Lists]
Advanced

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

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


From: Markus Armbruster
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 0/6] QTests: use Python to run complex tests
Date: Thu, 14 Dec 2017 17:05:03 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Nir Soffer <address@hidden> writes:

> On Thu, Dec 14, 2017 at 1:36 PM Paolo Bonzini <address@hidden> 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.  

> 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.



reply via email to

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