|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt |
Date: | Tue, 23 Mar 2010 19:55:15 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |