On 09/24/2014 02:09 PM, Dr. David Alan Gilbert wrote:
> This right here is a problem. Qemu has explicitly documented
that
> anything beginning with x- may be subject to change or going away in a
> later release, so libvirt policy has been to delay any patches
> targetting an x- interface until upstream qemu renames it to drop the x-
> to signify that it is now stable. So we can review your patches, but
> can't apply them yet.
It is a shame that libvirt doesn't have a similar mechanism which could
be used in conjunction with qemu. My reason for currently leaving the x-
in place is that while I don't expect the QML side to change, it seemed
fair to put a new feature into QEMU without locking it down for the
first cut. This seems to be normal practice in QEMU but invariably
means that libvirt support is delayed.
Libvirt DOES have the ability to issue raw monitor commands through
libvirt-qemu.so, and that might be sufficient for coding up the required
hacks. Or, if the libvirt proof of concept patches here do the job, we
can feed that back to the qemu community as proof that the feature works
enough to lose the x- prefix right away, and commit ourselves to the
interface. The benefit of a proof-of-concept patch done in parallel is
that the moment the upstream qemu feature is no longer experimental,
libvirt can apply the patches right away, and downstream distros can
backport those packages in situations where .so stability is not violated.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org