[Top][All Lists]

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

Re: [RFC PATCH v2 00/11] qemu_iotests: improve debugging options

From: Markus Armbruster
Subject: Re: [RFC PATCH v2 00/11] qemu_iotests: improve debugging options
Date: Thu, 08 Apr 2021 14:39:46 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Emanuele Giuseppe Esposito <eesposit@redhat.com> writes:

> On 08/04/2021 10:26, Markus Armbruster wrote:
>> Emanuele Giuseppe Esposito <eesposit@redhat.com> writes:
>>> This series adds the option to attach gdbserver and valgrind
>>> to the QEMU binary running in qemu_iotests.
>>> It also allows to redirect QEMU binaries output of the python tests
>>> to the stdout, instead of a log file.
>>> Patches 1-6 introduce the -gdb option to both python and bash tests,
>>> 7-10 extend the already existing -valgrind flag to work also on
>>> python tests, and patch 11 introduces -p to enable logging to stdout.
>>> In particular, patches 1,2,4,8 focus on extending the QMP socket timers
>>> when using gdb/valgrind, otherwise the python tests will fail due to
>>> delays in the QMP responses.
>>> This series is tested on the previous serie
>>> "qemu-iotests: quality of life improvements"
>>> but independent from it, so it can be applied separately.
>>> Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
>> How discoverable are these goodies for developers with only superficial
>> knowledge of iotests?
> Not really sure what you mean, but
> ./check --help now shows:
>> -p         enable prints
>> -gdb       start gdbserver with $GDB_QEMU options. Default is localhost:12345
> Which I guess should be clear enough? Btw two-three weeks ago I didn't 
> know anything about these tests either.
> I agree I can make -p more clear, saying "enable qemu binary prints to 
> stdout", and move -valgrind to the "optional arguments" instead of 
> "bash-only"

Yes, please (this is not a demand).

docs/devel/testing.rst section "QEMU iotests" is the place to explain
things in more detail than --help, if that's useful.  Right now it
simply points to check -h.

reply via email to

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