Anthony Liguori <anthony@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...]