Re: [Qemu-devel] Re: Machine-readable or parseable qemu output

[Avi Kivity]

Daniel P. Berrange wrote:
> Well if we have async messages over a separate channel, 

I dislike this intensely; IMO this is indicates the protocol is badly 
designed.  Of course, the qemu monitor protocol wasn't designed to do 
this, but we should fix this instead of finding workarounds.

> we can already
> reliably resynchronize with the output, because QEMU will eventually
> produce its '(qemu) ' prompt on a new line.

That's just begging for a nic or some other object named '(qemu) '.

Also, "if something goes wrong", recovering the prompt isn't helpful.  
The VM and the management interface are out of sync, any surprise can 
follow.  Better to disconnect, reconnect, and query for all state (like 
you do when the management application recovers from a crash).

>  So if something goes wrong
> you just need to skip until you find the prompt again.  Changing QEMU
> monitor prompt will just break all existing libvirt deployments, and
> any other programs relying on currently prompt.
>
> IMHO, any libqemumonitor.so should be made to work with current monitor
> format as its starting point, and then extend from there, not change
> any existing characteristics. This provides forwards & backwards compat
> for all apps, albeit at cost of slightly more complex internals for
> the libqemumonitor.so - but this complexity will be centralized in one
> place instead of all apps using QEMU, so this is still a net win.
>   

That means we'll be doomed to ad-hoc extensions forever, with extension 
N+1 needing to check the previous N extensions for compatibility.  I'd 
like to see a protocol with extensibility, asynchronity, and 
discoverability built in, not tacked on.  The old protocol can be 
supported separately but not extended any more.

--
error compiling committee.c: too many arguments to function