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

[Markus Armbruster]

Anthony Liguori <address@hidden> writes:

> 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.

Yes, the plan is to have QMP describe itself.  Needs work.

>>> 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 can't quite see what such a libqemu would buy us compared to straight
QMP.

Talking QMP should be easy, provided you got a suitable JSON library.

Generating a libqemu.so for (a particular version of) QMP may make
talking (that version of) QMP slightly easier in C, by turning a simple
text network protocol into a C API.  But it's not without drawbacks.

The text protocol is designed to be evolvable in backward-compatible
ways.  For instance, we can new add commands, new optional arguments,
and so forth.  But you can't add new optional arguments to C functions
without changing the API.  You can change the function and bump the
soname, or you can deprecate the function and add a new one, or you can
bypass static typing, e.g. by passing arguments in a dictionary.  In the
latter case, why not put the command in the dictionary as well, and cut
the number of functions from N to 1.

Ensured consistency of libqmp and QEMU sounds nice.  But it's consistent
with a *local* version of QEMU.  QMP is a *network* protocol.  If your
app talks QMP straight, it can handle any remote version it knows all by
itself.  If you interpose libqmp, you add a dependency: you need a
sufficiently current *local* QEMU/libqmp.

>> 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.

I suspect importing a foreign libqmp.so C API into a non-C language is
no easier than using the language's JSON facilities and talk QMP
straight, and less flexible.

> 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.

I can't quite see the utility of that.

[D-Bus snipped...]