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

Anthony Liguori anthony at codemonkey.ws
Wed Mar 24 00:55:15 UTC 2010


On 03/23/2010 06:25 PM, Jamie Lokier wrote:
> Alexander Graf wrote:
>    
>> I don't see why we shouldn't be able to automatically generate
>> libqemu.so. We have the *.hx files that describe the syntax of
>> parameters plus list all available options / commands. I'm not sure
>> how exactly QMP works, but having a generic QMP command to list all
>> available options would be handy too.
>>
>> By then we could automate most of the library, making the glueing
>> really easy. If libvirt doesn't properly link against libqemu anymore
>> we also know why: The ABI changed.
>>      
> I'm thinking most potential uses of the binary API, other than C
> programmers, would be happier with a D-Bus version generated from
> those same *.hx files.  Because then it's easy to call the API from
> Python, Perl, even shell, etc.  Whereas libqemu.so would be relatively
> difficult to use from those languages.
>    

My thinking with respect to libqemu.so is that it should be mostly 
autogenerated.

QMP supports introspection, we should be able to generate an idl 
description of QMP via introspection and then build all of the function 
stubs from that idl.  Then there is no opportunity for libqemu to be out 
of date.

All we really need to write for libqemu is some core bits to deal with 
transport specific issues.

> (Aside: I don't particularly like D-Bus.  But it does seem to work
> for this sort of thing.)
>    

I don't think d-bus is a good fit as a core qemu service.  It's not 
commonly used on other platform and it introduces quite a bit of 
overhead for non-Unix platforms.

But that certainly doesn't mean that a d-bus service implemented on top 
of libqemu (even autogenerated from our IDL) would be a bad project.

Regards,

Anthony Liguori

> -- Jamie
>    




More information about the libvir-list mailing list