Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt

[Anthony Liguori]

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://address@hidden/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