* Anthony Liguori (anthony@xxxxxxxxxxxxx) 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
