"Dr. David Alan Gilbert" <dgilb...@redhat.com> writes:
> * Peter Maydell (peter.mayd...@linaro.org) wrote:
>> On 29 September 2015 at 14:11, Dr. David Alan Gilbert
>> <dgilb...@redhat.com> wrote:
>> > * Peter Maydell (peter.mayd...@linaro.org) wrote:
>> >> On 28 September 2015 at 20:43, Programmingkid
>> >> <programmingk...@gmail.com> wrote:
>> >> >
>> >> > On Sep 28, 2015, at 3:29 AM, Markus Armbruster wrote:
>> >> >> You didn't mention you're talking about a *GUI* feature.
>> >> >
>> >> > I'm thinking it would be easier to send in the patch rather
>> >> > than talk about
>> >> > what this feature could be.
>> >>
>> >> I think Markus and I are trying to save you that effort by
>> >> pointing out that this is a VM management layer feature,
>> >> not a core QEMU feature.
>> >
>> > OK, so I'm going to agree with Programmingkid here.
>> > I think this would be a useful feature to have in QEMU; I've
>> > got gratuitous hacks in some of my test scripts that work
>> > around it not being there.
>> >
>> > I think there are two possible things, both of which seem fairly
>> > easy:
>> > 1) Add a -chardev from file that works in this case
>> > (I don't think the current chardev file works does it?)
In general, character devices provide a bidirectional pipe, but -chardev
file is write-only. I think you want -chardev pipe. I don't use it
myself, because as socat user, I don't have to learn lesser tools :)
Here's how I use it. Set up a local socket (any convenient
bidirectional pipe would do, actually).
Example: QMP
# Configuration file for -readconfig
[chardev "qmp"]
backend = "socket"
path = "sock-qmp"
server = "on"
wait = "off"
[mon "qmp"]
mode = "control"
chardev = "qmp"
Example: HMP
[chardev "hmp"]
backend = "socket"
path = "sock-hmp"
server = "on"
wait = "off"
[mon "hmp"]
mode = "readline"
chardev = "hmp"
Then do stuff with it.
Example: interactive QMP
$ socat UNIX:sock-qmp READLINE,history=$HOME/.qmp_history,prompt='QMP> '
Example: interactive HMP
$ socat UNIX:sock-hmp READLINE,history=$HOME/.hmp_history
Arguably superior to our built-in not-quite readline monitor.
Example: send QMP input from a file, capture its output in a file
$ socat UNIX:sock-qmp STDIO <input >output
>> > 2) A 'source' like command.
QMP? The command would have to take a filename as argument, and return
a list of replies. Probably stop on first failed command. Pretty
useless for remote clients, because if you have to upload the file, you
can just as well send it down the QMP pipe. Actually, that pretty much
applies to local clients, too. Except perhaps for interactive use. I
feel a QMP client geared for such use would be the appropriate home for
this feature. We have some in scripts/qmp/.
I don't have an opinion on HMP right now.
>> Yeah, these are both plausible. Neither of them are GUI features,
>> though...
>
> Well, I don't use the GTK gui; I can see that those who do
> might want features in it.
GUI users want GUI features, of course.
In my opinion, QEMU should leave them to separate GUI shells, because
doing everything in QEMU distracts from our core mission and we don't
have GUI expertise[*]. One more point: building in the GUI is
problematic when you don't trust the guest, because then you really want
to run QEMU with least privileges.
[*] Short version of the argument, for the long one, see
Message-ID: <87oahn51ys....@blackfin.pond.sub.org>
http://lists.gnu.org/archive/html/qemu-devel/2015-08/msg03916.html
