Re: [Qemu-devel] [PATCH v3 1/8] ahci-test: Add dependency to qemu-img tool

[Philippe Mathieu-Daudé]

On 2/8/19 11:34 PM, John Snow wrote:
> On 2/7/19 1:51 PM, Thomas Huth wrote:
>> On 2019-02-07 17:50, Philippe Mathieu-Daudé wrote:
>>> On 2/5/19 1:18 AM, Philippe Mathieu-Daudé wrote:
>>>> Since the ahci-test uses qemu-img, add a dependency to build it
>>>> before using it.
>>>> This fixes:
>>>>
>>>>   $ gmake check-qtest V=1
>>>>   QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 
>>>> QTEST_QEMU_IMG=qemu-img tests/ahci-test
>>>>   Failed to execute child process "/tmp/qemu-test.19tMRF/qemu-img" (No 
>>>> such file or directory)
>>>>   ERROR:tests/libqos/libqos.c:192:mkimg: assertion failed: (ret && !err)
>>>>
>>>> Reviewed-by: John Snow <address@hidden>
>>>> Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
>>>> ---
>>>> Slighly related is when vm-tests expect qemu-img available:
>>>> https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg08415.html
>>>>
>>>>   $ make vm-build-ubuntu.i386
>>>>   Traceback (most recent call last):
>>>>     File "source/qemu/tests/vm/basevm.py", line 236, in main
>>>>       return vm.build_image(args.image)
>>>>     File "tests/vm/ubuntu.i386", line 67, in build_image
>>>>       subprocess.check_call(["qemu-img", "resize", img_tmp, "50G"])
>>>>   OSError: [Errno 2] No such file or directory
>>>>   tests/vm/Makefile.include:23: recipe for target 
>>>> 'tests/vm/ubuntu.i386.img' failed
>>>>   make: *** [tests/vm/ubuntu.i386.img] Error 2
>>>>
>>>> A better fix would be checking those tools via ./configure...
>>>> ---
>>>>  tests/Makefile.include | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/tests/Makefile.include b/tests/Makefile.include
>>>> index 75ad9c0dd3..679656b64a 100644
>>>> --- a/tests/Makefile.include
>>>> +++ b/tests/Makefile.include
>>>> @@ -708,7 +708,7 @@ tests/prom-env-test$(EXESUF): tests/prom-env-test.o 
>>>> $(libqos-obj-y)
>>>>  tests/rtas-test$(EXESUF): tests/rtas-test.o $(libqos-spapr-obj-y)
>>>>  tests/fdc-test$(EXESUF): tests/fdc-test.o
>>>>  tests/ide-test$(EXESUF): tests/ide-test.o $(libqos-pc-obj-y)
>>>> -tests/ahci-test$(EXESUF): tests/ahci-test.o $(libqos-pc-obj-y)
>>>> +tests/ahci-test$(EXESUF): tests/ahci-test.o $(libqos-pc-obj-y) 
>>>> qemu-img$(EXESUF)
>>>
>>> In [*] Cleber noticed if we configure using --disable-tools, qemu-img is
>>> still built by when running "make check-block" due to this rule.
>>>
>>> I think this is OK because
>>> - at least a test requires it, so this test will run (which is what
>>>   we want)
>>> - while the tool is available in the build directory, it still won't
>>>   be installed by "make install"
>>
>> I guess you could also introduce a CONFIG_TOOLS switch and only run the
>> ahci test for CONFIG_TOOLS=y ? ... not that important, but in case you
>> respin the series, maybe worth a try.
>>
>>  Thomas
>>
> 
> Is this necessary?
> 
> You can run ahci-test by itself without building tools, but you need to
> export QTEST_QEMU_IMG yourself, which you can absolutely point to some
> other copy you have.
> 
> If you run "make check" though, it's going to use the built copy of
> qemu-img no matter what, isn't it? so what's so great about preserving a
> configuration where you ask it not to build tools and then intentionally
> try to execute tests that will necessarily fail because they can't find
> the qemu-img binary?
> 
> This seems fine the way it is, because you are asking the computer:
> 
> 1. Not to build tools, please
> 2. Actually, please make the tools so I can run the tests

I understand it the same way (although not being a computer).

I wanted to check if what Cleber noticed could bother someone else, but
I think the current behavior is the correct one.
Also I wouldn't worry much about this corner case, the combination of
having someone:
 - willing to run iotests
   AND
   (
      - doesn't have qemu-img distrib-installed
      OR
      - ran configure with --disable-tools
   )
is *very* unlikely, as only 2 person reported this and both encountered
this while working on QEMU testing.

> Convince me otherwise?
> --js
>