qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: John Snow <jsnow@redhat.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Max Reitz <mreitz@redhat.com>
Subject: Re: [PATCH 4/5] iotests: Skip "make check-block" if QEMU does not support virtio-blk
Date: Mon, 14 Oct 2019 13:21:26 +0200	[thread overview]
Message-ID: <20191014112126.GF7173@localhost.localdomain> (raw)
In-Reply-To: <20191011145047.19051-5-thuth@redhat.com>

Am 11.10.2019 um 16:50 hat Thomas Huth geschrieben:
> The next patch is going to add some python-based tests to the "auto"
> group, and these tests require virtio-blk to work properly. Running
> iotests without virtio-blk likely does not make too much sense anyway,
> so instead of adding a check for the availability of virtio-blk to each
> and every test (which does not sound very appealing), let's rather add
> a check for this at the top level in the check-block.sh script instead
> (so that it is possible to run "make check" without the "check-block"
> part for qemu-system-tricore for example).
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  tests/check-block.sh | 16 +++++++++++++++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/check-block.sh b/tests/check-block.sh
> index 679aedec50..7582347ec2 100755
> --- a/tests/check-block.sh
> +++ b/tests/check-block.sh
> @@ -26,10 +26,24 @@ if grep -q "CFLAGS.*-fsanitize" config-host.mak 2>/dev/null ; then
>      exit 0
>  fi
>  
> -if [ -z "$(find . -name 'qemu-system-*' -print)" ]; then
> +if [ -n "$QEMU_PROG" ]; then
> +    qemu_prog="$QEMU_PROG"
> +else
> +    for binary in *-softmmu/qemu-system-* ; do
> +        if [ -x "$binary" ]; then
> +            qemu_prog="$binary"
> +            break
> +        fi

Wouldn't it be better to check the availability of virtio-blk here, so
that if the current binary doesn't support it, we keep searching and
maybe pick up a different binary that supports it?

Or actually, should we work with a whitelist? We already need separate
code for s390 and x86_64 in some places to choose between -pci and -ccw,
and the presence of some virtio-blk doesn't mean that we know the
specifics of how to add a virtio-blk device for this target. This
suggests that blindly using a random binary might not be possible, but
tests may have to be adapted before the target can be whitelisted.

Kevin

> +    done
> +fi
> +if [ -z "$qemu_prog" ]; then
>      echo "No qemu-system binary available ==> Not running the qemu-iotests."
>      exit 0
>  fi
> +if ! "$qemu_prog" -M none -device help | grep virtio-blk >/dev/null 2>&1 ; then
> +    echo "$qemu_prog does not support virtio-blk ==> Not running the qemu-iotests."
> +    exit 0
> +fi
>  
>  if ! command -v bash >/dev/null 2>&1 ; then
>      echo "bash not available ==> Not running the qemu-iotests."
> -- 
> 2.18.1
> 


  reply	other threads:[~2019-10-14 11:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-11 14:50 [PATCH 0/5] Enable more iotests during "make check-block" Thomas Huth
2019-10-11 14:50 ` [PATCH 1/5] iotests: remove 'linux' from default supported platforms Thomas Huth
2019-10-18 16:15   ` Max Reitz
2019-10-11 14:50 ` [PATCH 2/5] iotests: Test 041 does not work on macOS Thomas Huth
2019-10-18 16:19   ` Max Reitz
2019-10-21  8:08     ` Thomas Huth
2019-10-11 14:50 ` [PATCH 3/5] iotests: Test 183 does not work on macOS and OpenBSD Thomas Huth
2019-10-11 14:50 ` [PATCH 4/5] iotests: Skip "make check-block" if QEMU does not support virtio-blk Thomas Huth
2019-10-14 11:21   ` Kevin Wolf [this message]
2019-10-14 11:27     ` Thomas Huth
2019-10-14 14:17       ` Kevin Wolf
2019-10-18 17:08   ` Max Reitz
2019-10-11 14:50 ` [PATCH 5/5] iotests: Enable more tests in the 'auto' group to improve test coverage Thomas Huth
2019-10-18 17:13   ` Max 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=20191014112126.GF7173@localhost.localdomain \
    --to=kwolf@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --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 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).