On 14.02.2018 16:27, Cornelia Huck wrote: > On Wed, 14 Feb 2018 09:15:23 -0600 > Eric Blake <ebl...@redhat.com> wrote: > >> On 02/14/2018 04:15 AM, Cornelia Huck wrote: >>> On Tue, 13 Feb 2018 18:18:48 +0100 >>> Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> wrote: >>> >> >>>> A suggestion was made on the mailing list to enhance the QAPI >>>> code generation to support two layers of unions. This would >>>> allow to specify the common fields once and avoid the duplication >>>> in the leaf unions. >>>> >>>> On the other hand, the slow query-cpus should be deprecated >>>> along with the slow CpuInfo type and eventually be removed. >>>> Assuming that new architectures will not be added at high >>>> rates, we could live with the duplication for the time being. >>> >>> What would be a realistic timeframe for deprecation/removal of >>> query-cpus, considering the libvirt usage? Are we aware of other users? >> >> Well, if we want to start the clock ticking, this series also needs to >> touch qemu-doc.texi to start the deprecation clock, then we go at least >> two more releases with support for both old and new commands. >> > > I'd like to know first what libvirt plans to do -- no sense in starting > deprecation if we're still stuck with it for a while. > FWIW, I'm currently preparing libvirt patches to use query-cpus-fast if available. I wouldn't see why it would take more than one libvirt release to get them in.
The question might rather be, which combinations of qemu and libvirt are considered useful. E.g., I didn't upgrade libvirt in a while on my test system but am using bleeding edge QEMU. But that doesn't necessarily resemble a valid setup. -- Regards, Viktor Mihajlovski
