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

On 03/25/2010 11:50 AM, Markus Armbruster wrote: > >> The point is, C is a lowest common denominator and it's important to >> support in a proper way. >> > No. The lowest truly common denominator is plain text. And we got that > covered already. > > A developer encountered the problem of talking a simple text protocol. > He thought "I know, I'll create a 1:1 C API for that". Now he got two > problems. > I've done a poor job communicating in this thread. The C API's primary purpose is *not* to providing 1:1 wrapping functions for QMP functions. That's a minor, add on feature, that I really would like, but it not at all useful for high level languages. The importances of libqemu is: 1) Providing a common QMP transport implementation that is extensible by third parties 2) Providing a set of common transports that support automatic discovery of command line launched guests 3) Providing a generic QMP dispatch function

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.