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

[Anthony Liguori <anthony@codemonkey.ws>]

Avi Kivity wrote:
> 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)

Yes.  The QEMU chrdev code can be reused too.

>> - 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.

+1

>> - The API could be something like:
>>   - execute_qemu_command(qemu_instance, command, args...);
>>
>>   
>
> It'd much prefer
>
> qemu_hotplug_nic(...);
> qemu_migrate(..., callback);

I concur.

>> - 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.

Agreed.

Regards,

Anthony Liguori