[Top][All Lists]

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

Re: venv for python qtest bits? (was: Re: [PATCH 11/12] acpi/tests/bits:

From: Ani Sinha
Subject: Re: venv for python qtest bits? (was: Re: [PATCH 11/12] acpi/tests/bits: add README file for bits qtests)
Date: Tue, 28 Jun 2022 19:23:32 +0530

On Tue, Jun 28, 2022 at 19:15 Peter Maydell <peter.maydell@linaro.org> wrote:
On Tue, 28 Jun 2022 at 14:23, Ani Sinha <ani@anisinha.ca> wrote:
> On Tue, Jun 28, 2022 at 6:25 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > This proposed biosbits test also involves a considerable download.
> I do not think 50 MB is "considerable" . Last time I tried to run
> avocado tests, my laptop ran out of disk space!

I think 50MB is pretty big. It might be smaller than some other
avocado tests, but it's not exactly the "no binary involved"
that most qtests are.

Well bios-tables-test uses the binary blobs of the acpi tables. Only difference is that in this case, we could maintain them within  the qemu tree. In this case the blob in slightly larger and comes from a third party. That is the difference. 

> > The test is said to be irrelevant for anyone except those working
> > on a fairly narrow set of QEMU firmware related bits.
> Well ok that is just a bad argument. You can say the same thing for
> most qtests. In fact, that is why most qtetes can run directly simply
> by passing QTEST_QEMU_BINARY in the environment. No need to go through
> make check. Same with the bits test. It can be run directly.

'make check' is generally the small, fast, no-binary-blobs tests.

See above.

Very few 'make check' tests even run code in the guest.

So bits test is similar here. It runs code in the guest vm.

> So by the same
> > rationale we shouldn't impose that burden on everyone working on
> > QEMU by having it in qtest.
> So why burden everyone by having bios-tables-test when it only affects
> acpi/smbios developers?

Because it's small and fast and doesn't have a binary blob to download.

There are definitely some awkwardnesses with 'check-avocado',
but we should work on fixing those, not use them as a reason
to refuse to put tests into the avocado tests if that's where
they fit best.

I think this test fits best in the qtrst not with the integration test framework. Very few path developers will ever run it and wrote new tests for it if we have it there. I would be terribly discouraged if that’s where this test landed.

-- PMM

reply via email to

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