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

[Avi Kivity <avi@redhat.com>]

Amit Shah wrote:
> Hello,
>
> Continuing from the thread at [1], building on Daniel's suggestions, I
> have jot down a few points as to how a libqemumonitor API could be
> developed.
>
> To recap, there has to be an interface to the qemu monitor in
> a way that wouldn't break even if the monitor output changes. This API
> will remain the same, so that consumers (libvirt, etc) can safely
> integrate with the monitor.
>
> Please see Dan's email at [1] to get the background details.
>
> [1] http://www.mail-archive.com/qemu-devel@nongnu.org/msg14615.html
>
> Here are some initial thoughts. Comments?
>
> - Have a libqemumonitor.so that will abstract out output from qemu and
>   provide a machine-readble output for the consumer
>
> - Registering with a particular qemu instance:
>   - qemu_instance = attach_to_qemu("/path/to/socket");
>   

qemu chrdev ("tcp:host:port", etc)

> - The strings in qemu monitor can change but the libqemumonitor has to
>   change accordingly as well to keep the API consistent.
>   

No, they can't.  The monitor client and qemu will be upgraded independently.

> - The API could be something like:
>   - execute_qemu_command(qemu_instance, command, args...);
>
>   

It'd much prefer

qemu_hotplug_nic(...);
qemu_migrate(..., callback);

> - In addition to the return value seen of the loglevel type from the
>   monitor, there can be additional return values that can be provided
>   based on the command executed. This can be queried by:
>   - get_info_on_prev_command(qemu_instance, &ret);
>   - This can give command-specific return values, like success,
>   invalid parameter, etc.
>   

No, the command handler should parse the output expected from executing 
the command.  If the command is asynchronous, the command handler should 
provide a callback.

> - The string generated by qemu monitor output should never be exposed to
>   the consumer
>   

Right.

> - Some monitor commands will generate some string that might be of use
>   to the consumer. Such a string will be passed to the consumer via some
>   other api, like
>   - get_string_from_last_command(qemu_instance, some_context);
>   

Output parameters will do fine.

> - There might be output that's asynchronous to the command. Finding the
>   correlation between the command and the output should not be the
>   library's job; an async_socket can be created per qemu instance and
>   the consumer can select() on this socket to poll for data. Whenever
>   some information becomes available, we can push it out. If the qemu
>   output would contain more information for async output, this can be
>   passed on to the consumer.
>   

You're moving the protocol handling out from the protocol parser...

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