All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: Max Reitz <mreitz@redhat.com>,
	qemu-block@nongnu.org, qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
	qemu-stable@nongnu.org, Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 3/4] iotests.py: rewrite run_job to be pickier
Date: Thu, 23 May 2019 12:16:30 -0400	[thread overview]
Message-ID: <eb7c1f50-74b9-5957-153c-696e56d099e4@redhat.com> (raw)
In-Reply-To: <1ccd5e06-7442-8767-c051-91348eed9d7a@redhat.com>



On 5/23/19 8:39 AM, Max Reitz wrote:
> On 10.05.19 21:03, John Snow wrote:
>> Don't pull events out of the queue that don't belong to us;
>> be choosier so that we can use this method to drive jobs that
>> were launched by transactions that may have more jobs.
>>
>> Signed-off-by: John Snow <jsnow@redhat.com>
>> ---
>>  tests/qemu-iotests/iotests.py | 32 +++++++++++++++-----------------
>>  1 file changed, 15 insertions(+), 17 deletions(-)
> 
> There are a couple of conflicts because of concurrent patches to run_job
> now.  I resolved those, but then noticed that the tests 245 and 255 no
> longer pass; their reference output contains events like
> BLOCK_JOB_PENDING and BLOCK_JOB_COMPLETED.
> 
> I’m not sure whether we should remove those event from the output.  It
> feels weird to me to keep them somewhere in the back log and not show
> them in tests that by design have kind of a full QMP log.  On the other
> hand, I see that this patch is necessary.  Ideally, I think run_job
> should log all events that relate to the job at hand -- but our current
> event_wait() matching system doesn’t allow that.
> 
> Ideas? :-/
> 

Amend event_wait to be able to wait for multiple events and criteria;
then amend run_job to wait for both legacy and contemporary job events.

Because all block_job_* events are omitted prior to the final transition
to the null state, they can remain optional waits. Whenever they are
present, they will be fully consumed and logged.

Patches comin' up.

> Max
> 



  reply	other threads:[~2019-05-23 16:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-10 19:03 [Qemu-devel] [PATCH v2 0/4] blockdev-backup: don't check aio_context too early John Snow
2019-05-10 19:03 ` [Qemu-devel] [PATCH v2 1/4] " John Snow
2019-05-10 19:03 ` [Qemu-devel] [PATCH v2 2/4] iotests.py: do not use infinite waits John Snow
2019-05-10 19:03 ` [Qemu-devel] [PATCH v2 3/4] iotests.py: rewrite run_job to be pickier John Snow
2019-05-23 12:39   ` Max Reitz
2019-05-23 16:16     ` John Snow [this message]
2019-05-10 19:03 ` [Qemu-devel] [PATCH v2 4/4] iotests: add iotest 250 for testing blockdev-backup across iothread contexts John Snow
2019-05-17 11:18   ` Max Reitz
2019-05-17 18:54     ` John Snow
2019-05-17  0:15 ` [Qemu-devel] [PATCH v2 0/4] blockdev-backup: don't check aio_context too early John Snow

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=eb7c1f50-74b9-5957-153c-696e56d099e4@redhat.com \
    --to=jsnow@redhat.com \
    --cc=armbru@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    /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.