Re: [Qemu-devel] [PATCH] iotests: Check for enabled drivers before testing them

[Max Reitz <mreitz@redhat.com>]

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

On 20.08.19 21:19, Thomas Huth wrote:
> On 8/20/19 8:48 PM, Max Reitz wrote:
>> On 20.08.19 18:01, Thomas Huth wrote:
> [...]
>>> Well, we disable blkverify in our downstream RHEL version of QEMU - so
>>> it would be great if the iotests could at least adapt to that missing
>>> driver.
>>
>> I would like to say that RHEL is not a gold standard
> 
> Well, let's put it this way: The less changes we have to carry along
> downstream (and thus review each time we rebase the downstream tree),
> the more time we have to work on upstream.

As I said, I’m guilty myself.

>> It feels a bit weird to me to say “blkverify is not essential, because
>> RHEL disables it, but null-co is” – even though there is no reason why
>> anyone would need null-co except for testing either.
> 
> Ok, fine for me, too, if we also declare "null-co" as optional for the
> iotests - let's make sure that the tests in the "auto" group also work
> without them.

Well, should we or not?  You said there are other tests (outside of the
iotests) that break without null-co.  If so, I don’t think there’s any
point in making it optional here.

>>>> Of course, that no longer works as an argument now that we
>>>> unconditionally run some iotests in make check.
>>>>
>>>> But still, the question is how strict you want to be.  If blkdebug
>>>> cannot be assumed to be present, what about null-co?  What about raw?
>>>
>>> I tried to disable everything beside qcow2 - but that causes so many
>>> things to fail that it hardly makes sense to try to get that working.
>>
>> Hm, really?  I just whitelisted qcow2 and file and running the auto
>> group worked rather well (except for the failing tests you address here,
>> and the two others I mentioned).
> 
> IIRC I tried to run all qcow2 tests when I disabled null-co and saw lots
> of failures ... but anyway, let's just focus on the "auto" tests right
> now, that should be doable.

OK, I didn’t bother running all. :-)

Max


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