Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API

[Anthony Liguori <anthony@codemonkey.ws>]

Daniel P. Berrange wrote:
> On Tue, Dec 11, 2007 at 08:51:32AM -0600, Anthony Liguori wrote:
>   
>> Dor Laor wrote:
>>     
>>> Laurent Vivier wrote:
>>>       
>>>> Le mardi 11 décembre 2007 à 10:10 +0100, Fabrice Bellard a écrit :
>>>>  
>>>>         
>>>>> Hi,
>>>>>    
>>>>>           
>>>> Hi,
>>>>
>>>>  
>>>>         
>>>>> At this point I am not interested in integrating it into QEMU as it is 
>>>>> one more API level to maintain in addition to the command line monitor. 
>>>>> However, I can change my mind if several projects insists to have a 
>>>>> similar interface.
>>>>>    
>>>>>           
>>>> perhaps the DBUS interface can replace the command line monitor ?
>>>> We have just to move the command line interface to a client speaking to
>>>> qemu through the DBUS interface.
>>>>
>>>>  
>>>>         
>>> This is a valid option but the problem is that local user will have to 
>>> use another tool (client) to
>>> send commands. Another option is to have a common backend with machine 
>>> & user interfaces.
>>> For example, if we use dbus as the backend, monitor commands will just 
>>> be translated into dbus.
>>> The opposite option is also valid.
>>>
>>> Anyway, the motivation behind a new interface is that the monitor 
>>> interface is not good enough for automation:
>>> There are not return status for commands, no option for async 
>>> notifications, no option for parallel actions in case
>>> a command takes long time to complete (like snapshot).
>>>       
>> All of these are valid, and addressable.  Return statuses can just be 
>> added to the beginning of the output of each command (similar to how 
>> POP3 works).  Async notification can be made to work by add support to 
>> the monitor for a "select" command.  Semantically, select would block 
>> the monitor and then output events.   For this to work really well, you 
>> would have to support multiple simultaneous monitor sessions.  The 
>> parallel options for long running commands is already address in KVM 
>> with the migration command.  We just have to rework the snapshotting to 
>> be properly asynchronous.
>>     
>
> Or have 2 monitor interaction modes. One mode uses the command line style
> suitable for people / scripting languages. The other umode ses a binary XDR
> protocol for serializing the args & returns values for formal control
> APIs to use in a easy manner. It ought to be reasonably straightforward to
> add a binary serialization format for all existing commands
>   

I don't think binary is inherently easier to parse than text provided 
that some thought is put into the format of the textual output.

I think we just want to levels of verbosity.

Regards,

Anthony Liguori

> Dan.
>