qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 3/3] iotests: blacklist bochs and cloop for 205


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 3/3] iotests: blacklist bochs and cloop for 205 and 208
Date: Mon, 9 Apr 2018 15:29:27 +0200
User-agent: Mutt/1.9.1 (2017-09-22)

Am 09.04.2018 um 13:30 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 03.04.2018 16:36, Kevin Wolf wrote:
> > Am 30.03.2018 um 17:16 hat Vladimir Sementsov-Ogievskiy geschrieben:
> > > Blacklist these formats, as they don't support image creation, as they
> > > say:
> > >      > ./qemu-img create -f bochs x 1m
> > >      qemu-img: x: Format driver 'bochs' does not support image creation
> > > 
> > >      > ./qemu-img create -f cloop x 1m
> > >      qemu-img: x: Format driver 'cloop' does not support image creation
> > > 
> > > Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
> > We can take this for now, but I think I would actually prefer a solution
> > like in the bash tests, where the $IMGFMT_GENERIC environment variable
> > is checked for "_supported_fmt generic".
> > 
> > I suppose in Python test cases, we can assume that generic is meant when
> > neither supported_fmts nor unsupported_fmts are given (or both are empty
> > lists).
> > 
> > Kevin
> 
> it may be ok for verify_image_format, as we can call it or not call (to
> support all formats).
> 
> but iotests main function always call verify_image_format, so, this
> will skip bochs and cloop for all iotests which call maind() without
> format restriction.

Yes, but that's what we want. Read-only formats can only be tested with
test cases made specifically for the respective format, because they
need to use a binary image from sample_images/.

I don't think there is a case where we really want to run the test for
all possible formats. Can you think of one?

> So, I think it is safer to directly mimic bash tests behavior - allow
> 'generic' as a member of supported_fmts.

That works, too, but I think it's not quite as nice.

Kevin



reply via email to

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