Anthony Liguori <anthony@xxxxxxxxxxxxx> 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...] -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list