Re: [Qemu-devel] Staging update (0.12 pending freeze)

[Anthony Liguori]

Luiz Capitulino wrote:
> On Thu, 03 Dec 2009 17:21:18 -0600
> Anthony Liguori <address@hidden> wrote:
>
>   
> > > Finally the 'default devices' patch series ('must have' IMHO):
> > >
> > >   http://patchwork.ozlabs.org/patch/39180/ (patch 1/10)
> > >
> > > Without that one using -device and -readconfig becomes much harder.
> > >       
> > This series doesn't get along with the QMP monitor support that's been 
> > added recently.  That's because there is now a set of monitor flags and 
> > -monitor takes more than a character device as an argument.
> >     
>
>  For QMP there is only one flag, which is 'control', like:
>
> -monitor control,<device>
>
>  Multiple Monitors work just fine, like:
>
> -monitor stdio -monitor control,tcp:localhost:444,server
>
>  I've even tested multiple QMP monitors iirc. :)
>
>   
> > Honestly, I don't really like multiplexing the -monitor option to 
> > support qmp.  I think I would have a proper -qmp option at the top 
> > level.  That would integrate much more nicely too with this default 
> > devices series.  Luiz, what do you think?
> >     
>
>  Multiplexing the monitor is really useful for testing and it doesn't
> seem reasonable to me to drop this feature just because we can't
> add a single flag to an existing command-line option.
>   

Problem is, control is not a property of the character device. To 
express this in a consistent way with everything else, you would have to 
make this QemuOpts-like so it would look like

-monitor control,device=tcp:localhost:444,server

But so far, the monitor, serial, parallel, etc. devices don't take QemuOpts.

OTH, having:

-qmp tcp:localhost:444,server

Matches the other option types in a consistent manner. If you want to 
support muxing, just add a qmp: prefix to the mux device.

Regards,

Anthony Liguori