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

[Anthony Liguori]

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