qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Markus Armbruster
Subject: Re: [Qemu-devel] feature idea: allow user to run custom scripts
Date: Thu, 01 Oct 2015 08:55:53 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

"Dr. David Alan Gilbert" <address@hidden> writes:

> * Markus Armbruster (address@hidden) wrote:
>> "Dr. David Alan Gilbert" <address@hidden> writes:
>> 
>> > * Peter Maydell (address@hidden) wrote:
>> >> On 29 September 2015 at 14:11, Dr. David Alan Gilbert
>> >> <address@hidden> wrote:
>> >> > * Peter Maydell (address@hidden) wrote:
>> >> >> On 28 September 2015 at 20:43, Programmingkid
>> >> >> <address@hidden> 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.

Have you tried -chardev pipe?  As I said, I don't use it myself, because
my "painful" setup is more flexible, and not painful at all once set up.

[...]



reply via email to

[Prev in Thread] Current Thread [Next in Thread]