[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH qemu] spapr: Stop providing RTAS
From: |
Greg Kurz |
Subject: |
Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH qemu] spapr: Stop providing RTAS blob |
Date: |
Thu, 18 Jul 2019 12:40:42 +0200 |
On Thu, 18 Jul 2019 17:55:12 +1000
Alexey Kardashevskiy <address@hidden> wrote:
>
>
> On 18/07/2019 17:20, Thomas Huth wrote:
> > On 16/07/2019 07.35, Alexey Kardashevskiy wrote:
> >> SLOF implements one itself so let's remove it from QEMU. It is one less
> >> image and simpler setup as the RTAS blob never stays in its initial place
> >> anyway as the guest OS always decides where to put it.
> >>
> >> This totally depends on https://patchwork.ozlabs.org/patch/1132440/ ,
> >> hence RFC.
> >
> > Patch looks basically fine for me, but I wonder whether we should wait
> > for one or two releases until we really remove it from QEMU, so that it
> > is still possible to test the latest QEMU with older SLOF releases for a
> > while (which is sometimes useful when hunting bugs). Or should this
> > maybe even go through the official deprecation process (i.e. with an
> > entry in qemu-deprecated.texi)?
>
> I worry more about slof being distributed as a separate package in RHEL,
> easy enough to get qemu/slof out of sync.
>
Then it seems to call for keeping the code around in QEMU in case RHEL's
slof doesn't implement the RTAS blob. Following the official deprecation
process looks like a good option IMHO.
>
Re: [Qemu-devel] [RFC PATCH qemu] spapr: Stop providing RTAS blob, David Gibson, 2019/07/18
Re: [Qemu-devel] [RFC PATCH qemu] spapr: Stop providing RTAS blob, Alexey Kardashevskiy, 2019/07/22