Re: [Qemu-devel] feature idea: allow user to run custom scripts

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Markus Armbruster (armbru@redhat.com) wrote:
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:
> 
> > * Peter Maydell (peter.maydell@linaro.org) wrote:
> >> On 29 September 2015 at 14:11, Dr. David Alan Gilbert
> >> <dgilbert@redhat.com> wrote:
> >> > * Peter Maydell (peter.maydell@linaro.org) wrote:
> >> >> On 28 September 2015 at 20:43, Programmingkid
> >> >> <programmingkidx@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.fsf@blackfin.pond.sub.org>
> http://lists.gnu.org/archive/html/qemu-devel/2015-08/msg03916.html
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK