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

["Daniel P. Berrange" <berrange@redhat.com>]

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

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|