On Mon, 15 Feb 2010 15:16:32 +0000 "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote: > On Mon, Feb 15, 2010 at 04:14:01PM +0100, Matthias Bolte wrote: > > 2010/2/15 Daniel P. Berrange <berrange@xxxxxxxxxx>: > > > --- > > > src/qemu/qemu_driver.c | 18 ++++++++++++++---- > > > src/qemu/qemu_monitor.c | 13 +++++++++++++ > > > src/qemu/qemu_monitor.h | 2 ++ > > > src/qemu/qemu_monitor_json.c | 20 ++++++++++++++++++++ > > > src/qemu/qemu_monitor_json.h | 2 ++ > > > 5 files changed, 51 insertions(+), 4 deletions(-) > > > > > > > ACK. > > > > Why do we need to call qmp_capabilities at startup? > > Because QEMU developers just decided to add it and make it mandatory :-) Actually, it's because when a client connects QMP is in "capabilities negotiation mode". In this mode only the qmp_capabilities command can be issued. When this is done QMP changes to "command mode", where all commands are accepted. This is QMP's capabilities negotiation support. It's a mandatory step because new capabilities are reserved for protocol changes or features which are not backward compatible. This way, it's important that server and clients agree on what is going to be on the wire before any message is exchanged. We don't have any capabilities yet, so qmp_capabilities is issued without arguments. Which is what clients should do if they don't support new features. > /me is happy the JSON code is still disabled until QEMU 0.13 comes out Well, I was in favor of making QMP stable for 0.12, but today I realize that this would have been a mistake, as the protocol wasn't mature yet. I understand that having to keep up to date with an unstable protocol isn't always fun, on the other hand libvirt's early adoption and your inputs are crucial to guide QMP's unstable phase into the right direction. Please, let me know if there's anything that we could improve on our side. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list