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
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
