qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Eric Blake <eblake@redhat.com>,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: "nsoffer@redhat.com" <nsoffer@redhat.com>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>
Subject: Re: [PATCH 0/2] enhance iotest 223 coverage
Date: Mon, 7 Oct 2019 13:44:43 +0200	[thread overview]
Message-ID: <e050358d-95a9-78b3-c219-a708bee75da6@redhat.com> (raw)
In-Reply-To: <473f7df2-9845-d90e-6dc9-0542ec2c3c76@redhat.com>


[-- Attachment #1.1: Type: text/plain, Size: 1817 bytes --]

On 24.09.19 21:51, Eric Blake wrote:
> On 9/24/19 2:26 PM, Vladimir Sementsov-Ogievskiy wrote:
>> 24.09.2019 17:35, Eric Blake wrote:
>>> Commit 506902c6 dropped non-iothread coverage in order to test iothread,
>>> better is to run things twice.  In doing this, I found it easier to
>>> edit the test when the log shows what commands were triggering various
>>> responses.
>>
>> Did you consider adding -iothread to tests/qemu-iotests/check instead, to be
>> able to run any (or some) tests with or without iothread?
> 
> I don't know how many of the existing iotests would benefit from the
> ability supply iothread as an option, nor how likely it is that someone
> would actually remember to run the testsuite twice to cover the use of
> that option.

I would, because I already run all qcow2 tests without any creation
options, with compat=0.10, and with refcount_bits=1.  (And plan to add
data_file=$TEST_IMG.data_file in the future.)

(And I let the iotests run through a script from some json description
files, so I won’t forget.)

> I also don't know how hard it would be to retrofit the
> addition of optional iothread support into all the tests.

That I don’t know either.  Though I think the point wouldn’t be to
retrofit iothread support into all tests, but just start with some.
(For example, 262 uses “an iothread just for fun”.  So it could clearly
run with both configurations.)

I do think it’s an interesting idea, but I don’t think it’s important
right now.

Max

> Rather, I
> addressed the more immediate concern of the fact that my recent addition
> to using iothread in 223 lost the previous ability of that test to cover
> non-iothread, and where this patch series now makes it cover both
> scenarios with a single iotests run.
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

      reply	other threads:[~2019-10-07 11:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-24 14:35 [PATCH 0/2] enhance iotest 223 coverage Eric Blake
2019-09-24 14:35 ` [PATCH 1/2] tests: Make iotest 223 easier to edit Eric Blake
2019-10-07 12:05   ` Max Reitz
2019-10-07 20:06     ` Eric Blake
2019-10-08  9:04       ` Max Reitz
2019-09-24 14:35 ` [PATCH 2/2] tests: More iotest 223 improvements Eric Blake
2019-10-07 12:14   ` Max Reitz
2019-09-24 19:26 ` [PATCH 0/2] enhance iotest 223 coverage Vladimir Sementsov-Ogievskiy
2019-09-24 19:51   ` Eric Blake
2019-10-07 11:44     ` Max Reitz [this message]

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=e050358d-95a9-78b3-c219-a708bee75da6@redhat.com \
    --to=mreitz@redhat.com \
    --cc=eblake@redhat.com \
    --cc=nsoffer@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@virtuozzo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).