Re: [Qemu-devel] [PATCH 0/3] build configuration query tool and conditional (qemu-io)test skip

[Cleber Rosa]

On 07/21/2017 10:01 AM, Daniel P. Berrange wrote:
> On Fri, Jul 21, 2017 at 01:33:25PM +0100, Stefan Hajnoczi wrote:
>> On Thu, Jul 20, 2017 at 11:47:27PM -0400, Cleber Rosa wrote:
>>> This is a follow up to a previous discussion about reported failures when
>>> running some qemu-iotests.  Turns out the failures were due to missing
>>> libraries, which in turn, reflected on the host build configuration.
>>>
>>> This series introduces a tool that can check both host and target level
>>> build configurations.  On top of that, it adds a function to to be used
>>> on qemu-iotests.  Finally, as an example, it sets a test to be skipped
>>> if the required feature is not enable on the host build configuration.
>>>
>>> Cleber Rosa (3):
>>>   scripts: introduce buildconf.py
>>>   qemu-iotests: add _require_feature() function
>>>   qemu-iotests: require CONFIG_LINUX_AIO for test 087
>>>
>>>  scripts/buildconf.py         | 278 
>>> +++++++++++++++++++++++++++++++++++++++++++
>>>  tests/qemu-iotests/087       |   1 +
>>>  tests/qemu-iotests/check     |   2 +
>>>  tests/qemu-iotests/common.rc |   7 ++
>>>  4 files changed, 288 insertions(+)
>>>
>>
>> It should be possible to run iotests against any
>> qemu/qemu-img/qemu-io/qemu-nbd binaries - even if no build root is
>> available.
> 
> For sake of argument, two options for non-buildroot scenario
> 
>  - assume all features are present, so we're no worse than we are today.
>  - install config.h (or same data in a structured format) to
>    /usr/share/qemu so its available for query
> 
> Downside of 2 of course is that other non-iotests apps might start
> to depend on it
> 

Actually, I see #2 as a worthy goal.  Not in the strict sense of the
implementation you suggested, but as a way for *any code* (including
non-iotests) to have a baseline to work with.

>> How about invoking qemu-img and tools to determine their capabilities?
>>
>> At the beginning of ./check, query the qemu/qemu-img/qemu-io/qemu-nbd
>> binaries for specific features.  This produces a set of available
>> features and tests can say:
>>
>>   _supported_feature aio_native
>>
>> This feature can be checked by opening an image file:
>>
>>   qemu-io --format raw --nocache --native-aio --cmd quit test.img
> 
> I think this is useful as a general approach, because there are bound
> to be a number of features which are available at compile time, but
> cannot actually be used at runtime. eg not every filesystem supports
> O_DIRECT, even if we've built support for it.
> 

I strongly believe this kind of ad hoc check has value, it complements
what is being proposed here, but doesn't replace it at all.  Using the
previous example, suppose a test is being written to test aio in various
filesystems.  It'd be extremely useful to rely on the information that
qemu-io itself has been built with native aio support.  With that
information as a safe baseline, and run time information about the
filesystem it's operating on, a much cleaner expected outcome can be
defined.

Without the static capabilities defined, the dynamic check would be
influenced by the run time environment.  It would really mean "qemu-io
running on this environment (filesystem?) can do native aio".  Again,
that's not the best type of information to depend on when writing tests.

> Regards,
> Daniel
> 

Regards!

-- 
Cleber Rosa
[ Sr Software Engineer - Virtualization Team - Red Hat ]
[ Avocado Test Framework - avocado-framework.github.io ]
[  7ABB 96EB 8B46 B94D 5E0F  E9BB 657E 8D33 A5F2 09F3  ]

signature.asc
Description: OpenPGP digital signature