Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/26/2010 02:37 AM, Markus Armbruster wrote:
Adding to this C wrappers for QMP commands threatens to make QMP
command
arguments part of the library ABI. Compatible QMP evolution (like
adding an optional argument) turns into a libqmp soname bump.
Counter-productive. How do you plan to avoid that?
I had thought about this. I think there's a couple ways to handle it.
You could ignore it and just not change existing symbols. You could
also introduce new functions any time an optional argument is added.
Another option is to add a struct as a final argument whenever such a
change happens that's padded. Then new optional arguments can be added
to the struct.
> Yes, this means you can't just create a JSON-RPC object in
Python and
> talk QMP that way, but that's less desirable than you think it is.
>
> You could if you really wanted to, but you wouldn't get the benefits
> of the common transports.
>
> IOW, imagine qemu-cmd. You want it to support:
>
> # qmp_new_by_name("Fedora")
> qemu-cmd Fedora set_link on
>
> # libqemu-ssh.so - ssh_qmp_new()
> qemu-cmd ssh://anthony@lab1.ibm/Fedora set_link on
>
> # qmp_new_by_fd()
> qemu-cmd -c /path/to/domain/socket set_link on
>
> # libvirt-qemu.so - virDomainGetQMP()
> qemu-cmd -b qemu+ssh://lab1.ibm/system Fedora set_link on
>
> This requires a high level transport.
>
All I'd want from such a transport is a file descriptor. No need to
drag in yet another JSON library via libqmp.
Then you don't standardize creation which is probably where most of the
complexity occurs.
Regards,
Anthony Liguori