Daniel P. Berrangé <[email protected]> writes: > On Mon, Jun 08, 2026 at 04:13:02PM -0300, Fabiano Rosas wrote: >> Thomas Huth <[email protected]> writes: >> >> > On 30/05/2026 16.56, Ani Sinha wrote: >> >> Hi, >> >> >> >> I am trying to write a qtest for which I need an IGVM file. I have the >> >> file, about 54 MiB in size. >> > >> > 54 MiB is quite big, I agree that we likely don't want to check that into >> > the main repository, especially if it is for a test only... >> > (BTW, what's its compressed size?) >> > >> >> Instead of committing this IGVM binary >> >> file with the test, I wanted to check if I can put it somewhere, say >> >> in a gitlab repo and then make the test download it. This would be >> >> similar to asset downloads for functional tests. No this test cannot >> >> be a python functional test. I am wondering if anyone has faced this >> >> situation before and what the best way to solve this problem is. >> > >> > I'm not maintaining the qtests anymore, but I assume that there is no >> > interest in duplicating all the asset downloading logic there. >> > >> >> It would be nice if we could extract the existing code into a little >> asset library that could be invoked from the other test frameworks. > > IMHO that isn't really practical, all the asset handling is in python. > It'd be mad to re-implement that in C and then call it from python, > and the C isn't really going to call the current python either.... >
What about a standalone downloader? I'm still thinking about reusing more of the common operations between test frameworks. Is it feasible to have a cmdline app that can be invoked by qtest and place artifacts in a common place? >> > What's the exact reason why you cannot do it as a functional test instead? >> > You could maybe also start the qemu binary there with "-accel qtest -qtest >> > ..." to fake a qtest environment - a little bit cumbersome, but certainly >> > doable, I think. > > ..if we didn't have the historical baggage already, then I'd that > qtests should conceptually just be a subset of the functional > tests. Writing them in python would be nicer than doing them in C. > But could we make _working_ with them in python be equivalent to C? I agree it's nice to write tests in a higher level language, but python specifically is a big pain when it comes to actually finding out why a test is failing. And debugging is even worse. The tradeoff is that unittest is clearly superior to glib as a test runner. Having a more modern way of generating command-lines would be nice too. > The qtest service is integrated in QEMU, what's missing is > > * the client side to talk the qtest protocol python/qemu/machine/qtest.py? > * the various bus specific helper APIs > > I don't know how hard it would be to bootstrap the client side in > python, but the general qtest protocol is 2000 lines of C, so > probably more like 500 lines of python to replace it, plus whatever > helpers you might want on top. Probably not terribly much work to > get something useful kickstarted. > > NB, I am *not* sugggesting re-writing the actual existing tests, > just make it possible to write new qtests in python. > > With regards, > Daniel
