All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: Thomas Huth <thuth@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	qemu-devel@nongnu.org
Cc: Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 1/3] libqtest: Ignore QMP events when parsing the response for HMP commands
Date: Tue, 4 Apr 2017 10:33:47 -0400	[thread overview]
Message-ID: <55a17a77-9ab4-519a-b917-695fd33fd4be@redhat.com> (raw)
In-Reply-To: <678cd353-56cb-3dac-3f91-966cb5abeb34@redhat.com>



On 04/04/2017 03:31 AM, Thomas Huth wrote:
> On 03.04.2017 21:09, John Snow wrote:
>>
>>
>> On 03/30/2017 03:50 AM, Thomas Huth wrote:
>>> When running certain HMP commands (like "device_del") via QMP, we
>>> can sometimes get a QMP event in the response first, so that the
>>> "g_assert(ret)" statement in qtest_hmp() triggers and the test
>>> fails. Fix this by ignoring such QMP events while looking for the
>>> real return value from QMP.
>>>
>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>> ---
>>>  tests/libqtest.c | 6 ++++++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/tests/libqtest.c b/tests/libqtest.c
>>> index a5c3d2b..c9b2d76 100644
>>> --- a/tests/libqtest.c
>>> +++ b/tests/libqtest.c
>>> @@ -580,6 +580,12 @@ char *qtest_hmpv(QTestState *s, const char *fmt, va_list ap)
>>>                       " 'arguments': {'command-line': %s}}",
>>>                       cmd);
>>>      ret = g_strdup(qdict_get_try_str(resp, "return"));
>>> +    while (ret == NULL && qdict_get_try_str(resp, "event")) {
>>> +        /* Ignore asynchronous QMP events */
>>> +        QDECREF(resp);
>>> +        resp = qtest_qmp_receive(s);
>>> +        ret = g_strdup(qdict_get_try_str(resp, "return"));
>>> +    }
>>>      g_assert(ret);
>>>      QDECREF(resp);
>>>      g_free(cmd);
>>>
>>
>> You've probably been asked this, but can you just shove the QMP response
>> you don't want into the event queue for consumption by other calls?
> 
> Well, this is the qtest_hmpv() function, so I assume that the caller
> just wants to execute a HMP command and does not really care about QMP
> events. If you care about QMP events, you should use the qmp functions
> instead.
> 
>  Thomas
> 

I don't think it's obvious that using HMP functions should cause the QMP
stream to become faulty, though.

If someone uses an HMP function and then tries to wait on a QMP event to
confirm that some key condition has occurred (pausing or resuming, for
instance) it would not be immediately apparent from the user's POV that
this function just eats replies because it was convenient to do so.

I guess the event queue only exists in python though, so it's not as
trivial as I was thinking it would be...

  reply	other threads:[~2017-04-04 14:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-30  7:50 [Qemu-devel] [PATCH v2 0/3] Add a tester for HMP commands Thomas Huth
2017-03-30  7:50 ` [Qemu-devel] [PATCH v2 1/3] libqtest: Ignore QMP events when parsing the response " Thomas Huth
2017-04-03 19:09   ` John Snow
2017-04-04  7:31     ` Thomas Huth
2017-04-04 14:33       ` John Snow [this message]
2017-04-07 17:58         ` Dr. David Alan Gilbert
2017-04-11  9:12         ` Markus Armbruster
2017-04-24 11:31           ` Dr. David Alan Gilbert
2017-04-24 12:23             ` Markus Armbruster
2017-03-30  7:50 ` [Qemu-devel] [PATCH v2 2/3] libqtest: Add a generic function to run a callback function for every machine Thomas Huth
2017-04-03 19:14   ` Philippe Mathieu-Daudé
2017-03-30  7:50 ` [Qemu-devel] [PATCH v2 3/3] tests: Add a tester for HMP commands Thomas Huth
2017-04-24 11:23   ` Dr. David Alan Gilbert
2017-04-28  1:56   ` Eric Blake
2017-06-27  2:55   ` Eric Blake
2017-06-29 11:48     ` Dr. David Alan Gilbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55a17a77-9ab4-519a-b917-695fd33fd4be@redhat.com \
    --to=jsnow@redhat.com \
    --cc=armbru@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.