[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: Mon, 18 Dec 2017 11:09:28 -0500 (EST)

> C code can reuse existing header files for struct definitions instead
> of doing oid, pnm, psn = struct.unpack(">x2s5sxLxxx", data).

On the other hand, C code risks having the same bug in tests and
device models, and also endianness is less apparent in C.  Overall
I'd say it's a wash---if I were to start now I'd use Python but I
agree with you that fragmenting the tests is not a good idea.

For the purpose of testing the SD card code, I'd use the SD-over-SSI
device.  Unfortunately there is no board that uses bit-banging SSI,
but STM32F405 is as close as it can get to it.


> In general, Python's model for binary data is a marshalling (copy) model
> rather than a type casting (in-place access) model.  It's fine for some
> things but programs that deal with a lot of raw data may use third-party
> unboxed data primitives like numpy's instead.  I definitely wouldn't say
> that binary I/O is a strength of Python.
> > > 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/).
> > >
> > 
> > You can write today code that work with both python 2 and 3. For binary
> > io the key is using io.FileIO and io.BytesIO instead of open() and StringIO
> > and CStringIO.
> Yes, it's possible to write the code carefully and test under both
> Python 2 & 3.  We have to do that for Python code in QEMU since the
> world is currently transitioning and both Python versions are in use.
> So in this case, where it's questionable to start a new device-level
> testing framework in the first place, the extra trouble of dealing with
> Python 2 & 3 makes it even less appealing.
> Stefan

reply via email to

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