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

[Dor Laor]

Daniel P. Berrange wrote:
> On Wed, Jan 14, 2009 at 11:29:38AM +0000, Richard W.M. Jones wrote:
>   
> > On Wed, Jan 14, 2009 at 04:40:05PM +0530, Amit Shah wrote:
> >     
> > > - Have a libqemumonitor.so that will abstract out output from qemu and
> > >   provide a machine-readble output for the consumer
> > >       
> > Why do we need a C API at all?  IMHO it'd be better just to make the
> > existing qemu monitor output more machine-friendly, meaning consistent
> > delimiters so that programs can reliably resynchronize with the
> > output, and consistent guarantees on error messages.
> >     
>
> Well if we have async messages over a separate channel, we can already
> reliably resynchronize with the output, because QEMU will eventually
> produce its '(qemu) ' prompt on a new line. 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.
>
> Daniel
>   
What about something like this:
- Extend the struct term_cmd_t we have today to support
 async commands, and offer callbacks and status callback (can be the 
same one)
- All the commands return binary results, some with enum for translating 
into strings later on
- The monitor instance is responsible for translating (potentially) the 
binary into text.
- Each such term_cmd_t will be registered (even dynamically) to the 
monitor interface.
- We can have multiple monitors running.
   - Each of them can be defined for sync/async commands.
- Every monitor instance can be a different implementation
 - monitor instance #1 will parse/print the output one way, instance #2 
-  a bit different
- The interface for adding monitor commands:
   - add_cmd(term_cmd_t *cmd)
   - del_cmd(term_cmd_t *cmd)
- The interface for libmonitor:
   - un/register_monitor(monitor_t *m)
- All of the commands define the in/out structures in a common
 location for libmonitor to parse.

This way each monitor instance can define the messages it handles 
(async,sync,in,out,etc).
Several monitors can live in parallel and even several implementations 
for parsing.
The default access would be the qemu_chr_device.
The current behavior should be the first implementation of libmonitor.so.
Others (aka machine readable) will follow soon.

Dor