qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 00/17] iotests: don't choke on disabled drivers


From: Roman Kagan
Subject: Re: [Qemu-devel] [PATCH 00/17] iotests: don't choke on disabled drivers
Date: Wed, 30 May 2018 16:47:38 +0300
User-agent: Mutt/1.9.5 (2018-04-13)

On Wed, May 30, 2018 at 02:35:34PM +0200, Max Reitz wrote:
> On 2018-04-26 18:19, Roman Kagan wrote:
> > Some iotests assume availability of certain block drivers, and fail if
> > the driver is not supported by QEMU because it was disabled at configure
> > time.
> > 
> > This series tries to address that, by making QEMU report the actual list
> > of supported block drivers in response to "-drive format=?", and using
> > this information to skip the parts of the io testsuite that can not be
> > run in this configuration.
> > 
> > Roman Kagan (17):
> >   block: iterate_format with account of whitelisting
> >   iotests: iotests.py: prevent deadlock in subprocess
> >   iotests: ask qemu for supported formats
> >   iotest 030: skip quorum test setup/teardown too
> >   iotest 030: require blkdebug
> >   iotest 055: skip unsupported backup target formats
> >   iotest 055: require blkdebug
> >   iotest 056: skip testcases using blkdebug if disabled
> >   iotest 071: notrun if blkdebug or blkverify is disabled
> >   iotest 081: notrun if quorum is disabled
> >   iotest 087: notrun if null-co is disabled
> >   iotest 093: notrun if null-co or null-aio is disabled
> >   iotest 099: notrun if blkdebug or blkverify is disabled
> >   iotest 124: skip testcases using blkdebug if disabled
> >   iotest 139: skip testcases using disabled drivers
> >   iotest 147: notrun if nbd is disabled
> >   iotest 184: notrun if null-co or throttle is disabled
> > 
> >  include/block/block.h         |  2 +-
> >  block.c                       | 23 ++++++++++++++++++----
> >  blockdev.c                    |  4 +++-
> >  qemu-img.c                    |  2 +-
> >  tests/qemu-iotests/030        |  7 +++++++
> >  tests/qemu-iotests/055        | 13 ++++++++++++
> >  tests/qemu-iotests/056        |  3 +++
> >  tests/qemu-iotests/071        |  1 +
> >  tests/qemu-iotests/081        |  1 +
> >  tests/qemu-iotests/087        |  1 +
> >  tests/qemu-iotests/093        |  1 +
> >  tests/qemu-iotests/099        |  1 +
> >  tests/qemu-iotests/124        |  5 +++++
> >  tests/qemu-iotests/139        |  4 ++++
> >  tests/qemu-iotests/147        |  1 +
> >  tests/qemu-iotests/184        |  1 +
> >  tests/qemu-iotests/common.rc  | 19 ++++++++++++++++++
> >  tests/qemu-iotests/iotests.py | 46 
> > ++++++++++++++++++++++++++++++++-----------
> >  18 files changed, 117 insertions(+), 18 deletions(-)
> 
> I'll stop reviewing this series for now, because there are more iotests
> that use drivers outside of their format/protocol combination.
> 
> For instance:
> 
> $ grep -l null-co ??? | wc -l
> 15
> $ grep -l blkdebug ??? | wc -l
> 30
> $ (grep -l '"raw"' ???; grep -l "'raw'" ???) | wc -l
> 22
> 
> As I've written in my reply to patch 8, I'm not sure whether it's the
> right solution to check for the availability of these block drivers in
> every single test that needs them.  It makes sense for quorum, because
> quorum needs an external library for hashing, so it may not be trivial
> to enable.  But it does not seem too useful for other formats that do
> not have such a dependency (e.g. null-co, blkdebug, raw).
> 
> The thing is that it's OK to whitelist everything for testing, and then
> disable some drivers when building a release.  I don't think one needs
> to run the iotests with the release version if the whole difference is
> whether some drivers have been disabled or not.

This patchset was created when we started to run (quick) iotests as a part
of the package build, which looked like a decent alternative to building
separate CI infrastructure.

If there's no general interest in running iotests against QEMU built in
a release configuration with certain drivers blacklisted, I think we
should be fine handling this locally.

Thanks,
Roman.



reply via email to

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