qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v2] libqtest: refuse QTEST_QEMU_BINARY=qemu-kvm


From: Peter Maydell
Subject: Re: [PATCH v2] libqtest: refuse QTEST_QEMU_BINARY=qemu-kvm
Date: Mon, 12 Apr 2021 10:50:20 +0100

On Mon, 12 Apr 2021 at 10:35, Thomas Huth <thuth@redhat.com> wrote:
>
> On 12/04/2021 11.18, Stefan Hajnoczi wrote:
> > Some downstreams rename the QEMU binary to "qemu-kvm". This breaks
> > qtest_get_arch(), which attempts to parse the target architecture from
> > the QTEST_QEMU_BINARY environment variable.
> >
> > Print an error instead of returning the architecture "kvm". Things fail
> > in weird ways when the architecture string is bogus.
> >
> > Arguably qtests should always be run in a build directory instead of
> > against an installed QEMU. In any case, printing a clear error when this
> > happens is helpful.
> >
> > Reported-by: Qin Wang <qinwang@rehdat.com>
> > Cc: Emanuele Giuseppe Esposito <eesposit@redhat.com>
> > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > ---
> >   tests/qtest/libqtest.c | 10 ++++++++++
> >   1 file changed, 10 insertions(+)
> >
> > diff --git a/tests/qtest/libqtest.c b/tests/qtest/libqtest.c
> > index 71e359efcd..7caf20f56b 100644
> > --- a/tests/qtest/libqtest.c
> > +++ b/tests/qtest/libqtest.c
> > @@ -910,6 +910,16 @@ const char *qtest_get_arch(void)
> >           abort();
> >       }
> >
> > +    if (!strstr(qemu, "-system-")) {
> > +        fprintf(stderr, "QTEST_QEMU_BINARY must end with *-system-<arch> 
> > where "
> > +                        "'arch' is the target architecture (x86_64, 
> > aarch64, "
> > +                        "etc). If you are using qemu-kvm or another custom 
> > "
> > +                        "name, please create a symlink like ln -s "
> > +                        "path/to/qemu-kvm qemu-system-x86_64 and use that "
> > +                        "instead.\n");
>
> The text is very long ... maybe add some \n to wrap it after 80 columns?
> (also not sure whether we really need the second part about the symlink...
> but I also don't mind leaving it in)

Yeah, anybody who runs into this is doing something weird and can
be assumed to be able to figure out how to do what they want with
a name of the right form, I think. You'll never see it if you're
just running 'make check'.

thanks
-- PMM



reply via email to

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