qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Hanna Reitz <hreitz@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	qemu-block@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, Thomas Huth <thuth@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [PATCH 2/2] iotests/303: Check for zstd support
Date: Wed, 2 Mar 2022 12:09:22 +0100	[thread overview]
Message-ID: <17a2a9e8-b0a0-8cd0-f3e3-4e4d71437d45@redhat.com> (raw)
In-Reply-To: <e4e63939-d4c3-795b-1270-0d3f74477ec3@virtuozzo.com>

On 22.02.22 16:55, Vladimir Sementsov-Ogievskiy wrote:
> 21.02.2022 20:08, Hanna Reitz wrote:
>> 303 runs two test cases, one of which requires zstd support.
>> Unfortunately, given that this is not a unittest-style test, we cannot
>> easily skip that single case, and instead can only skip the whole test.
>>
>> (Alternatively, we could split this test into a zlib and a zstd part,
>> but that seems excessive, given that this test is not in auto and thus
>> likely only run by developers who have zstd support compiled in.)
>>
>> Fixes: 677e0bae686e7c670a71d1f ("iotest 303: explicit compression type")
>> Signed-off-by: Hanna Reitz <hreitz@redhat.com>
>> ---
>>   tests/qemu-iotests/303 | 15 +++++++++++----
>>   1 file changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/tests/qemu-iotests/303 b/tests/qemu-iotests/303
>> index 16c2e10827..5a3efb4ba3 100755
>> --- a/tests/qemu-iotests/303
>> +++ b/tests/qemu-iotests/303
>> @@ -21,7 +21,8 @@
>>     import iotests
>>   import subprocess
>> -from iotests import qemu_img_create, qemu_io, file_path, log, 
>> filter_qemu_io
>> +from iotests import notrun, qemu_img_pipe_and_status, qemu_io, 
>> file_path, \
>> +        log, filter_qemu_io
>>     iotests.script_initialize(supported_fmts=['qcow2'],
>> unsupported_imgopts=['refcount_bits', 'compat'])
>> @@ -55,9 +56,15 @@ def add_bitmap(num, begin, end, disabled):
>>       def test(compression_type: str, json_output: bool) -> None:
>> -    qemu_img_create('-f', iotests.imgfmt,
>> -                    '-o', f'compression_type={compression_type}',
>> -                    disk, '10M')
>> +    opts = f'compression_type={compression_type}'
>> +    output, status = qemu_img_pipe_and_status('create',
>> +                                              '-f', iotests.imgfmt,
>> +                                              '-o', opts,
>> +                                              disk, '10M')
>> +    if status == 1 and \
>> +            "'compression-type' does not accept value 'zstd'" in 
>> output:
>> +        notrun('zstd compression not supported')
>> +
>
> Could we make from it a function in iotests.py like has_working_luks() 
> / verify_working_luks() ?
>
> Then in this test we'll simply have at start iotests.verify_zstd(), 
> and in previous test we'll do something like "comp_type = 'zstd' if 
> iotests.has_zstd() else 'zlib'" in classes that wants zstd

Well, to be honest, I deliberately didn’t do that.  We have qemu-img 
create calls in both of these places, where we can simply check the 
returned error string for free, basically.  Adding a function for this 
check doesn’t really reduce complexity (now), because adding such 
functions probably has some more LoC than just checking the returned 
error string in these two places (I say “now” because it’s possible that 
more places are added in the future, though, of course).  With zstd 
support compiled in, such functions would effectively also just add a 
superfluous qemu-img create call wherever they’re used.

I’m not saying I’m right about that judgment, because it does feel a bit 
like premature optimization.  Just saying why I didn’t add such functions.

So, with that said, would you still prefer such iotests.py functions?  
I’ll absolutely add them in v2 if you do.

Hanna



  reply	other threads:[~2022-03-02 12:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-21 17:08 [PATCH 0/2] iotests: Check for zstd support Hanna Reitz
2022-02-21 17:08 ` [PATCH 1/2] iotests/065: " Hanna Reitz
2022-02-21 17:20   ` Thomas Huth
2022-02-22 15:44   ` Vladimir Sementsov-Ogievskiy
2022-03-02 11:14     ` Hanna Reitz
2022-02-21 17:08 ` [PATCH 2/2] iotests/303: " Hanna Reitz
2022-02-21 17:27   ` Thomas Huth
2022-02-22 15:55   ` Vladimir Sementsov-Ogievskiy
2022-03-02 11:09     ` Hanna Reitz [this message]
2022-03-02 11:31       ` Vladimir Sementsov-Ogievskiy
2022-03-02 11:37         ` Hanna Reitz

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=17a2a9e8-b0a0-8cd0-f3e3-4e4d71437d45@redhat.com \
    --to=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    --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).