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