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



Reply via email to