On 2/15/21 1:27 PM, Cleber Rosa wrote:
It's hard to find the right balance here. If you take a look at what John
is proposing wrt the packaging the "qemu" Python libs, I believe one module
is a good compromise at this point. I really to expect that it will grow
and that more modules will be created.
Yeah. We have a "qmp" package and a "machine" package, and these seem
very well-defined.
Then we have everything else which is mostly a few random bits and
pieces (at the moment: just accel.py). Over time those bits and pieces
might take shape as something more important/meaningful, but for now
it's pretty nebulous.
An emerging pattern I see is that these functions are "environment
analysis" helpers; things designed to help interrogate the local
environment to choose appropriate QEMU flags, or otherwise "QEMU output
analysis", things designed to make better sense of the output received
from QEMU.
accel.py is the former, this patch targets the latter.
I suspect accel.py will want to belong to "smart" tools for booting up
an arbitrary VM (interrogate, decide on config, launch) whereas this
patch fits into a class of API-esque tools designed for making sense of
I/O information.
It's meant to digest HMP, though -- is this evidence that we need a
better QMP command? We shouldn't be using HMP for machine driven
testing. (I know we have to sometimes, but we should be working towards
eliminating it.)
-js
