Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Anthony Liguori <anthony(a)codemonkey.ws> 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...]