Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file

[Stefano Stabellini]

Daniel P. Berrange wrote:

> On Wed, Jun 24, 2009 at 01:32:12PM +0100, James wrote:
>>> It depends what you mean by 'dbus' here. I don't think managing QEMU over
>>> the dbus bus provides the right architecture - I don't think you want
>>> every QEMU appearing on the bus.  5B You could do direct peer-to-peer comms
>>> so you're just using libdbus for message encapsulation / processing, but
>>> there's not really much above XDR. XDR is nice because its a portable
>>> library that works on any OS, including OS-X and WIndows, and solely
>>> concerns itself with data encoding, not data transport.  
>> That leaves the rendezvous, and security issues to be re-invented wheels,
>> you could use SUNRPC and XDR. That has an excellent IDL. 
>>
>> I don't see why you wouldn't want it on the 'bus', and more than you'd want 
>> it
>> bound to a tcp port on localhost. It would make things a lot simpler: 
>> something
>> like a little command line utility to connect a CDROM or ISO image to a Qemu
>> instance which would be identified by some uuid or name would be very easy to
>> implement. 
> 
> This is exactly why I don't want it on the bus. I don't think the monitor
> interface is the general end-developer/user administrative interface. It
> is a control channel by which a mgmt tool will control QEMU, with the mgmt
> tool providing the end-developer/user admin interface. If someone wants
> to write a management app that controls QEMU instances and exposes an
> API on dbus that's fine, but the individual QEMU instances should not be
> directly exposed for use.
> 

Why qemu shouldn't provide a monitor interface on dbus?
The mgmt tool could still control qemu and provide the
end-developer/user admin interface anyway.