qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 3/4] iotests.py: rewrite run_job to be pickie


From: John Snow
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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1


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 <address@hidden>
>> ---
>>  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 via email to

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