On 4/4/22 22:34, John Snow wrote:
> On Wed, Mar 16, 2022 at 5:55 AM Damien Hedde <damien.hedde@greensocs.com> wrote:
>>
>> It takes an input file containing raw qmp commands (concatenated json
>> dicts) and send all commands one by one to a qmp server. When one
>> command fails, it exits.
>>
>> As a convenience, it can also wrap the qemu process to avoid having
>> to start qemu in background. When wrapping qemu, the program returns
>> only when the qemu process terminates.
>>
>> Signed-off-by: Damien Hedde <damien.hedde@greensocs.com>
>> ---
>>
>> Hi all,
>>
>> Following our discussion, I've started this. What do you think ?
>>
>> I tried to follow Daniel's qmp-shell-wrap. I think it is
>> better to have similar options (eg: logging). There is also room
>> for factorizing code if we want to keep them aligned and ease
>> maintenance.
>>
>> There are still some pylint issues (too many branches in main and it
>> does not like my context manager if else line). But it's kind of a
>> mess to fix theses so I think it's enough for a first version.
>
> Yeah, don't worry about these. You can just tell pylint to shut up
> while you prototype. Sometimes it's just not worth spending more time
> on a more beautiful factoring. Oh well.
>
>>
>> I name that qmp-send as Daniel proposed, maybe qmp-test matches better
>> what I'm doing there ?
>>
>
> I think I agree with Dan's response.
>
>> Thanks,
>> Damien
>> ---
>> python/qemu/aqmp/qmp_send.py | 229 +++++++++++++++++++++++++++++++++++
>
> I recommend putting this in qemu/util/qmp_send.py instead.
>
> I'm in the process of pulling out the AQMP lib and hosting it
> separately. Scripts like this I think should stay in the QEMU tree, so
> moving it to util instead is probably best. Otherwise, I'll *really*
> have to commit to the syntax, and that's probably a bigger hurdle than
> you want to deal with.
If it stays in QEMU tree, what licensing should I use ? LGPL does not
hurt, no ?
Whichever you please. GPLv2+ would be convenient and harmonizes well with other tools. LGPL is only something I started doing so that the "qemu.qmp" package would be LGPL. Licensing the tools as LGPL was just a sin of convenience so I could claim a single license for the whole wheel/egg/tgz.
(I didn't want to make separate qmp and qmp-tools packages.)
Go with what you feel is best.
>
>> scripts/qmp/qmp-send | 11 ++
>> 2 files changed, 240 insertions(+)
>> create mode 100644 python/qemu/aqmp/qmp_send.py
>> create mode 100755 scripts/qmp/qmp-send
>>
>> diff --git a/python/qemu/aqmp/qmp_send.py b/python/qemu/aqmp/qmp_send.py
>> new file mode 100644
>> index 0000000000..cbca1d0205
>> --- /dev/null
>> +++ b/python/qemu/aqmp/qmp_send.py
>
> Seems broadly fine to me, but I didn't review closely this time. If it
> works for you, it works for me.
>
> As for making QEMU hang: there's a few things you could do, take a
> look at iotests and see how they handle timeout blocks in synchronous
> code -- iotests.py line 696 or so, "class Timeout". When writing async
> code, you can also do stuff like this:
>
> async def foo():
> await asyncio.wait_for(qmp.execute("some-command", args_etc), timeout=30)
>
> See https://docs.python.org/3/library/asyncio-task.html#asyncio.wait_for
>
> --js
>
Thanks for the tip,
--
Damien
Oh, and one more. the legacy.py bindings for AQMP also support a configurable timeout that applies to most API calls by default.
(Branch still in limbo here, but it should still be close to the same in qemu.git)
I believe this is used by iotests.py when it sets up its machine.py subclass ("VM", iirc) so that most qmp invocations in iotests have a default timeout and won't hang tests indefinitely.
--js