* Anthony Liguori (anthony(a)codemonkey.ws) wrote:
On 03/15/2011 09:53 AM, Chris Wright wrote:
> QAPI
<snip>
>- c library implementation is critical to have unit tests and
test
> driven development
> - thread safe?
> - no shared state, no statics.
> - threading model requires lock for the qmp session
> - licensiing?
> - LGPL
> - forwards/backwards compat?
> - designed with that in mind see wiki:
>
>
http://wiki.qemu.org/Features/QAPI
One neat feature of libqmp is that once libvirt has a better QMP
passthrough interface, we can create a QmpSession that uses libvirt.
It would look something like:
QmpSession *libqmp_session_new_libvirt(virDomainPtr dom);
Looks like you mean this?
-> request QmpSession ->
client libvirt
<- return QmpSession <-
client -> QmpSession -> QMP -> QEMU
So bypassing libvirt completely to actually use the session?
Currently, it's more like:
client -> QemuMonitorCommand -> libvirt -> QMP -> QEMU
The QmpSession returned by this call can then be used with all of
the libqmp interfaces. This means we can still exercise our test
suite with a guest launched through libvirt. It also should make
the libvirt pass through interface a bit easier to consume by third
parties.
This sounds like it's something libvirt folks should be involved with.
At the very least, this mode is there now and considered basically
unstable/experimental/developer use:
"Qemu monitor command '%s' executed; libvirt results may be
unpredictable!"
So likely some concern about making it easier to use, esp. assuming
that third parties above are mgmt apps, not just developers.
thanks,
-chris