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

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.


Anthony Liguori

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