Nir Soffer <nir...@gmail.com> writes: > On Thu, Dec 14, 2017 at 1:36 PM Paolo Bonzini <pbonz...@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. > 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.