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

[Anthony Liguori <anthony@codemonkey.ws>]

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.

Regards,

Anthony Liguori