Luiz Capitulino wrote:
On Thu, 03 Dec 2009 17:21:18 -0600
Anthony Liguori <anth...@codemonkey.ws> 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