* Markus Armbruster (arm...@redhat.com) wrote: > "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
Yes, this example is exactly why I want something less painful. A -chardev file that allowed read/write would be ideal, to be able to read a series of commands at startup. > >> > 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. If QMP doesn't have a user for it fine; I'm just saying it would be useful from my point of view in HMP. > >> 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. Given that we have a built in GUI then I can see people wanting to expand it. Dave > > > [*] 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 -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK