diff mbox

new SDL keyboard shortcuts to start and stop VM

Message ID 20091022124036.5df991f3@doriath
State New
Headers show

Commit Message

Luiz Capitulino Oct. 22, 2009, 2:40 p.m. UTC
On Wed, 21 Oct 2009 19:35:03 +0100
Jamie Lokier <jamie@shareable.org> wrote:

> Mulyadi Santosa wrote:
> > On Wed, Oct 21, 2009 at 11:24 PM, Glauber Costa <glommer@gmail.com> wrote:
> > > You can provide a monitor command to do that
> > >
> > > something in the lines of:
> > > - add_macro <key> <command_list>
> > > - remove_macro <key>
> > > - list_macros
> > 
> > Please CMIIW, "command_list" here refers to at least one of monitor
> > commands, right? meaning, i.e one could do:
> > add_macro ctrl_alt_shift_s "stop"
> > 
> > or extend that so it does:
> > add_macro ctrl_alt_shift_s "stop print $pc"
> > 
> > so, it stops the VM followed by printing program counter.
> 
> If the monitor accepted ";" as a command separator, to put multiple
> commands on a single line, <command_list> could just be a quoted
> string which is processed as a line.

 Why is ";" needed?

> If we're going to have keyboard macros, it would be nice and probably
> very easy to have monitor macros too - monitor commands which expand
> to a line in the same way.
> 
> The number of times I've typed things like send_key control-alt-del
> and would have appreciated a "cad" macro...

 Yeah, I agree.

 When testing migration, for example, I have to type 'migrate -d tcp:0:4444'
several times... Maybe there's a smarter way to do this, but the monitor
macros idea seems interesting to me.

> Syntax idea comes to mind is:
> 
>     - Add ";" as command separator.

 Not difficult, but not trivial.

>     - add_macro <name> <command-string>
>     - remove_macro <name>
>     - list_macros

 Why not macro_add?

> 
>     - add_key key <key> <command-string>
>     - remove_key <key> <command-string>
>     - list_keys

 What's key?

 Anyway, below there's a patch with an initial implementation. I've
implemented it using the "old" monitor style because I didn't want
to think about the right "object model" for this yet..

 If people think this is interesting I will work on a serious
implementation for submission.

 Ah, it doesn't have macro_del and if we use QObjects we can
consider saving its json representation in file so that we can
have macro_load.

commit e7fa305f82f4f99168166bda437e86d3a6343064
Author: Luiz Capitulino <lcapitulino@redhat.com>
Date:   Thu Oct 22 12:26:06 2009 -0200

    monitor: Add macro support
    
    This is a buggy, untested, initial implementation, which only supports
    "macro_add" and "macro_list".
    
    Example:
    
    (qemu) macro_add mi "migrate -d tcp:localhost:4444"
    
    Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>

Comments

Kevin Wolf Oct. 22, 2009, 3:02 p.m. UTC | #1
Am 22.10.2009 16:40, schrieb Luiz Capitulino:
> On Wed, 21 Oct 2009 19:35:03 +0100
> Jamie Lokier <jamie@shareable.org> wrote:
>> If the monitor accepted ";" as a command separator, to put multiple
>> commands on a single line, <command_list> could just be a quoted
>> string which is processed as a line.
> 
>  Why is ";" needed?

How else would you specify multiple commands for one macro?

>>
>>     - add_key key <key> <command-string>
>>     - remove_key <key> <command-string>
>>     - list_keys
> 
>  What's key?

Some kind of key binding. If we allowed all keys, it would probably make
sense to use the sendkeys style format, but I assume we'll only support
ctrl-alt-<letter> which already has a special meaning.

>  Ah, it doesn't have macro_del and if we use QObjects we can
> consider saving its json representation in file so that we can
> have macro_load.

You are thinking about having this to avoid typing in the macro each
time you start a VM? For something the user might want to touch I'd
prefer a simple solution like reading ~/.qemurc or something like that
and executing it as a "monitor script".

Kevin
Anthony Liguori Oct. 22, 2009, 3:40 p.m. UTC | #2
Luiz Capitulino wrote:
>  Yeah, I agree.
>
>  When testing migration, for example, I have to type 'migrate -d tcp:0:4444'
> several times... Maybe there's a smarter way to do this, but the monitor
> macros idea seems interesting to me.
>   

When we have QMP, we can create a QMP socket at a well known location 
based on the -name parameter.  We could also introduce a qm command that 
allowed one to execute monitor commands from the shell.  That allows 
people to write whatever crazy shell scripts they want.

Regards,

Anthony Liguori
Luiz Capitulino Oct. 22, 2009, 4:32 p.m. UTC | #3
On Thu, 22 Oct 2009 17:02:29 +0200
Kevin Wolf <kwolf@redhat.com> wrote:

> Am 22.10.2009 16:40, schrieb Luiz Capitulino:
> > On Wed, 21 Oct 2009 19:35:03 +0100
> > Jamie Lokier <jamie@shareable.org> wrote:
> >> If the monitor accepted ";" as a command separator, to put multiple
> >> commands on a single line, <command_list> could just be a quoted
> >> string which is processed as a line.
> > 
> >  Why is ";" needed?
> 
> How else would you specify multiple commands for one macro?

 Let me rephrase this better: what use cases do we have for
multiple commands in one line/macro?

> >>     - add_key key <key> <command-string>
> >>     - remove_key <key> <command-string>
> >>     - list_keys
> > 
> >  What's key?
> 
> Some kind of key binding. If we allowed all keys, it would probably make
> sense to use the sendkeys style format, but I assume we'll only support
> ctrl-alt-<letter> which already has a special meaning.

 Ah, I see now. Would have to think about this.

> >  Ah, it doesn't have macro_del and if we use QObjects we can
> > consider saving its json representation in file so that we can
> > have macro_load.
> 
> You are thinking about having this to avoid typing in the macro each
> time you start a VM?

 Yes.

> For something the user might want to touch I'd
> prefer a simple solution like reading ~/.qemurc or something like that
> and executing it as a "monitor script".

 That's right, asking the user to edit json doesn't seem like
a good idea.. I guess I'm working too much with it. :)
Luiz Capitulino Oct. 22, 2009, 4:38 p.m. UTC | #4
On Thu, 22 Oct 2009 10:40:54 -0500
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Luiz Capitulino wrote:
> >  Yeah, I agree.
> >
> >  When testing migration, for example, I have to type 'migrate -d tcp:0:4444'
> > several times... Maybe there's a smarter way to do this, but the monitor
> > macros idea seems interesting to me.
> >   
> 
> When we have QMP, we can create a QMP socket at a well known location 
> based on the -name parameter.  We could also introduce a qm command that 
> allowed one to execute monitor commands from the shell.  That allows 
> people to write whatever crazy shell scripts they want.

 Yes.

 What about the macros idea? Are you against it?
Anthony Liguori Oct. 22, 2009, 6:32 p.m. UTC | #5
Luiz Capitulino wrote:
> On Thu, 22 Oct 2009 10:40:54 -0500
> Anthony Liguori <anthony@codemonkey.ws> wrote:
>
>   
>> Luiz Capitulino wrote:
>>     
>>>  Yeah, I agree.
>>>
>>>  When testing migration, for example, I have to type 'migrate -d tcp:0:4444'
>>> several times... Maybe there's a smarter way to do this, but the monitor
>>> macros idea seems interesting to me.
>>>   
>>>       
>> When we have QMP, we can create a QMP socket at a well known location 
>> based on the -name parameter.  We could also introduce a qm command that 
>> allowed one to execute monitor commands from the shell.  That allows 
>> people to write whatever crazy shell scripts they want.
>>     
>
>  Yes.
>
>  What about the macros idea? Are you against it?
>   

I'm concerned that it's a snowball of complexity waiting to happen for 
very little benefit.

I think we're trying to solve a non-existent problem.

Regards,

Anthony Liguori
Kevin Wolf Oct. 23, 2009, 7:40 a.m. UTC | #6
Am 23.10.2009 01:55, schrieb Juan Quintela:
> Anthony Liguori <anthony@codemonkey.ws> wrote:
>> Luiz Capitulino wrote:
>>> On Thu, 22 Oct 2009 10:40:54 -0500
>>> Anthony Liguori <anthony@codemonkey.ws> wrote:
>>>
>>>   
>>>> Luiz Capitulino wrote:
>>>>     
>>>>>  Yeah, I agree.
>>>>>
>>>>>  When testing migration, for example, I have to type 'migrate -d tcp:0:4444'
>>>>> several times... Maybe there's a smarter way to do this, but the monitor
>>>>> macros idea seems interesting to me.
>>>>>         
>>>> When we have QMP, we can create a QMP socket at a well known
>>>> location based on the -name parameter.  We could also introduce a
>>>> qm command that allowed one to execute monitor commands from the
>>>> shell.  That allows people to write whatever crazy shell scripts
>>>> they want.
>>>>     
>>>
>>>  Yes.
>>>
>>>  What about the macros idea? Are you against it?
>>>   
>>
>> I'm concerned that it's a snowball of complexity waiting to happen for
>> very little benefit.
>>
>> I think we're trying to solve a non-existent problem.
> 
> I fully agree.  If we have a had to issue commands to the monitor, we
> can use whatever shell/interpreter/... that we like.

But I can't bind a keyboard shortcut to such a script which is exactly
what this thread is about... What I want to have in the end is my "VM
stop" shortcut, dynamically binding keys to monitor commands is just a
way to achieve this.

I really hate this "You don't need this, I know it better" attitude. If
it were only for the technical arguments, okay - I can understand that
you don't want to add another magic key, and yes, doing it dynamically
comes with some complexity. But all this talking about "non-existent
problems" makes me think that you don't... really care about what users
want if they are the wrong users (yes, I admit, this one is useful more
likely for developers and plain qemu users than for those running their
servers in KVM - but they are still users, right?)

Kevin
Mulyadi Santosa Oct. 23, 2009, 11:23 a.m. UTC | #7
On Fri, Oct 23, 2009 at 2:40 PM, Kevin Wolf <kwolf@redhat.com> wrote:
> I really hate this "You don't need this, I know it better" attitude. If
> it were only for the technical arguments, okay - I can understand that
> you don't want to add another magic key, and yes, doing it dynamically
> comes with some complexity. But all this talking about "non-existent
> problems" makes me think that you don't... really care about what users
> want if they are the wrong users (yes, I admit, this one is useful more
> likely for developers and plain qemu users than for those running their
> servers in KVM - but they are still users, right?)

OK, everybody, please calm down.... please remember that this thread
started from my simple patch that wants to implement something that I
personally feel useful.

So, from both pros and cons side, I try to read and study your arguments.

Meanwhile, I have another idea. I admit I never redirect Qemu monitor
to certain char device. perhaps, if I could simply write a HOWTO on
how to use this feature to implement simple monitor shortcuts, then it
will be acceptable solution.

I imagine the steps would be:
1. redirect monitor to a certain char device
2. make a script that send commands to this device
3. bind new  KDE or GNOME shortcuts to call this script.

Critics?
Kevin Wolf Oct. 23, 2009, 11:45 a.m. UTC | #8
Am 23.10.2009 13:23, schrieb Mulyadi Santosa:
> On Fri, Oct 23, 2009 at 2:40 PM, Kevin Wolf <kwolf@redhat.com> wrote:
>> I really hate this "You don't need this, I know it better" attitude. If
>> it were only for the technical arguments, okay - I can understand that
>> you don't want to add another magic key, and yes, doing it dynamically
>> comes with some complexity. But all this talking about "non-existent
>> problems" makes me think that you don't... really care about what users
>> want if they are the wrong users (yes, I admit, this one is useful more
>> likely for developers and plain qemu users than for those running their
>> servers in KVM - but they are still users, right?)
> 
> OK, everybody, please calm down.... please remember that this thread
> started from my simple patch that wants to implement something that I
> personally feel useful.
> 
> So, from both pros and cons side, I try to read and study your arguments.
> 
> Meanwhile, I have another idea. I admit I never redirect Qemu monitor
> to certain char device. perhaps, if I could simply write a HOWTO on
> how to use this feature to implement simple monitor shortcuts, then it
> will be acceptable solution.
> 
> I imagine the steps would be:
> 1. redirect monitor to a certain char device
> 2. make a script that send commands to this device
> 3. bind new  KDE or GNOME shortcuts to call this script.

Well, the whole point of a keyboard shortcut was for me to make things
easier. Having to pass -monitor with the right magic file, writing a
script and assigning a global (!) shortcut isn't exactly what I would
call easier. I can keep using the monitor manually on TCP then.

Kevin
Anthony Liguori Oct. 23, 2009, 1:59 p.m. UTC | #9
Kevin Wolf wrote:
> Well, the whole point of a keyboard shortcut was for me to make things
> easier.

This is something of a classic debate between providing power users 
every possible knob and function verses overwhelming non-power users 
with so many features/options that they cannot even get started.

My big problem with keyboard shortcuts is that they are a really awful 
user interface for anything because they are not discoverable (without 
consulting documentation) and they provide no obvious feedback as to 
what state they are in.

For instance, imagine creating a shortcut based on a monitor macro of 
'migrate "exec:dd of=snapshot.img"' and you tie it to ctrl-alt-e.

What feedback do you get that the command has completed?  What happens 
if you try to run the command again while another is running?  Does it 
get queued, does it get dropped?  I can imagine a user sitting there 
hitting ctrl-alt-e repeatedly not realizing anything is happening.  I 
know I find myself doing this sometimes with ctrl-a when using -nographic.

Your answer may be, this is for a developer and they'll be aware of all 
the short comings/gotchas but this ends up being a rather user-hostile 
interface.  People are never as aware of short comings/gotchas as we'd 
like them to be.  If there was no other way for a developer to do this, 
I'd be more inclined to find a way to support this but it's just a 
matter of writing a script or if you really need a short cut, you can do 
it with standard gnome short cuts or write a very simple vnc client 
based on gvncviewer (we're talking a dozen lines of added code) to do 
this for you.

Regards,

Anthony Liguori
Kevin Wolf Oct. 23, 2009, 2:36 p.m. UTC | #10
Am 23.10.2009 15:59, schrieb Anthony Liguori:
> Kevin Wolf wrote:
>> Well, the whole point of a keyboard shortcut was for me to make things
>> easier.
> 
> This is something of a classic debate between providing power users 
> every possible knob and function verses overwhelming non-power users 
> with so many features/options that they cannot even get started.

You mean the additional monitor commands would overwhelm the non-power
users who can cope with the existing commands? This is a subjective
thing, so I can't contradict, but I'm not sure if I come to the same
conclusion. Do non-power users even use the monitor?

> 
> My big problem with keyboard shortcuts is that they are a really awful 
> user interface for anything because they are not discoverable (without 
> consulting documentation) and they provide no obvious feedback as to 
> what state they are in.

Right, with our interface they are not discoverable. I didn't know about
Ctrl-Alt-U, for example. But if I can list them in the monitor and even
more if I'm defining the shortcuts myself I'm pretty confident that I
can remember them.

> For instance, imagine creating a shortcut based on a monitor macro of 
> 'migrate "exec:dd of=snapshot.img"' and you tie it to ctrl-alt-e.
> 
> What feedback do you get that the command has completed?  What happens 
> if you try to run the command again while another is running?  Does it 
> get queued, does it get dropped?  I can imagine a user sitting there 
> hitting ctrl-alt-e repeatedly not realizing anything is happening.  I 
> know I find myself doing this sometimes with ctrl-a when using -nographic.

The user has created that ctrl-alt-e mapping himself, so he should know
how to use the monitor. He even knows the syntax of migrate, so chances
are that he also knows what it's doing.

> Your answer may be, this is for a developer and they'll be aware of all 
> the short comings/gotchas but this ends up being a rather user-hostile 
> interface.  People are never as aware of short comings/gotchas as we'd 
> like them to be.  If there was no other way for a developer to do this, 
> I'd be more inclined to find a way to support this but it's just a 
> matter of writing a script or if you really need a short cut, you can do 
> it with standard gnome short cuts or write a very simple vnc client 
> based on gvncviewer (we're talking a dozen lines of added code) to do 
> this for you.

No, sorry, before I start writing a VNC viewer I'd rather keep a local
patch around. ;-)

But I really don't feel like continuing this discussion as I don't see
anyone who could be convinced to change his opinion. I have one opinion,
you have a different one, maintainer wins. Let's move on to more
productive things.

Kevin
Avi Kivity Oct. 25, 2009, 3:28 p.m. UTC | #11
On 10/23/2009 03:59 PM, Anthony Liguori wrote:
> Your answer may be, this is for a developer and they'll be aware of 
> all the short comings/gotchas but this ends up being a rather 
> user-hostile interface.  People are never as aware of short 
> comings/gotchas as we'd like them to be.  If there was no other way 
> for a developer to do this, I'd be more inclined to find a way to 
> support this but it's just a matter of writing a script or if you 
> really need a short cut, you can do it with standard gnome short cuts 
> or write a very simple vnc client based on gvncviewer (we're talking a 
> dozen lines of added code) to do this for you.
>

vncviewer based displays may work now, but they are inefficient and will 
likely fall apart if/when we have 3D support.

I'd much rather see a real GUI client, perhaps implemented by scripting 
QObjects or QMP.
Luiz Capitulino Oct. 25, 2009, 3:44 p.m. UTC | #12
On Sun, 25 Oct 2009 17:28:33 +0200
Avi Kivity <avi@redhat.com> wrote:

> On 10/23/2009 03:59 PM, Anthony Liguori wrote:
> > Your answer may be, this is for a developer and they'll be aware of 
> > all the short comings/gotchas but this ends up being a rather 
> > user-hostile interface.  People are never as aware of short 
> > comings/gotchas as we'd like them to be.  If there was no other way 
> > for a developer to do this, I'd be more inclined to find a way to 
> > support this but it's just a matter of writing a script or if you 
> > really need a short cut, you can do it with standard gnome short cuts 
> > or write a very simple vnc client based on gvncviewer (we're talking a 
> > dozen lines of added code) to do this for you.
> >
> 
> vncviewer based displays may work now, but they are inefficient and will 
> likely fall apart if/when we have 3D support.
> 
> I'd much rather see a real GUI client, perhaps implemented by scripting 
> QObjects or QMP.

 A natural step for existing ones, they could also provide a shell by
their own.

 An interesting question is whether we should remove features from the
current shell when the time comes..
Anthony Liguori Oct. 26, 2009, 1:45 p.m. UTC | #13
Avi Kivity wrote:
> On 10/23/2009 03:59 PM, Anthony Liguori wrote:
>> Your answer may be, this is for a developer and they'll be aware of 
>> all the short comings/gotchas but this ends up being a rather 
>> user-hostile interface.  People are never as aware of short 
>> comings/gotchas as we'd like them to be.  If there was no other way 
>> for a developer to do this, I'd be more inclined to find a way to 
>> support this but it's just a matter of writing a script or if you 
>> really need a short cut, you can do it with standard gnome short cuts 
>> or write a very simple vnc client based on gvncviewer (we're talking 
>> a dozen lines of added code) to do this for you.
>>
>
> vncviewer based displays may work now, but they are inefficient and 
> will likely fall apart if/when we have 3D support.

If it's chromium based (which I suspect it will be), you could certainly 
tunnel it via vnc.

> I'd much rather see a real GUI client, perhaps implemented by 
> scripting QObjects or QMP.

I'm with you 100% here.  I'd rather see our focus put into a proper gui 
based on QMP than to tack on features to SDL.

Regards,

Anthony Liguori
Avi Kivity Oct. 26, 2009, 2:13 p.m. UTC | #14
On 10/26/2009 03:45 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
>> On 10/23/2009 03:59 PM, Anthony Liguori wrote:
>>> Your answer may be, this is for a developer and they'll be aware of 
>>> all the short comings/gotchas but this ends up being a rather 
>>> user-hostile interface.  People are never as aware of short 
>>> comings/gotchas as we'd like them to be.  If there was no other way 
>>> for a developer to do this, I'd be more inclined to find a way to 
>>> support this but it's just a matter of writing a script or if you 
>>> really need a short cut, you can do it with standard gnome short 
>>> cuts or write a very simple vnc client based on gvncviewer (we're 
>>> talking a dozen lines of added code) to do this for you.
>>>
>>
>> vncviewer based displays may work now, but they are inefficient and 
>> will likely fall apart if/when we have 3D support.
>
> If it's chromium based (which I suspect it will be), you could 
> certainly tunnel it via vnc.

But you wouldn't want to.  You'd probably get decent throughput at the 
expense of greater cpu consumption.  Much better to have qemu talk to drm.

>
>> I'd much rather see a real GUI client, perhaps implemented by 
>> scripting QObjects or QMP.
>
> I'm with you 100% here.  I'd rather see our focus put into a proper 
> gui based on QMP than to tack on features to SDL.
>

Maybe slightly less than 100%.  I meant a native GUI in the same process 
as qemu, but talking to QObjects through a scripting language.
Anthony Liguori Oct. 26, 2009, 3:04 p.m. UTC | #15
Avi Kivity wrote:
>>
>>> I'd much rather see a real GUI client, perhaps implemented by 
>>> scripting QObjects or QMP.
>>
>> I'm with you 100% here.  I'd rather see our focus put into a proper 
>> gui based on QMP than to tack on features to SDL.
>>
>
> Maybe slightly less than 100%.  I meant a native GUI in the same 
> process as qemu, but talking to QObjects through a scripting language.

The trouble here is that if you want to support being able to close the 
gui and open it again without killing the guest, you need the guest to 
live in a separate process.

The way VMware does it is by having a VNC extension that allows a shared 
memory transport which limits the CPU overhead.

Regards,

Anthony Liguori
Avi Kivity Oct. 26, 2009, 3:07 p.m. UTC | #16
On 10/26/2009 05:04 PM, Anthony Liguori wrote:
>> Maybe slightly less than 100%.  I meant a native GUI in the same 
>> process as qemu, but talking to QObjects through a scripting language.
>
>
> The trouble here is that if you want to support being able to close 
> the gui and open it again without killing the guest, you need the 
> guest to live in a separate process.
>

Many applications minimize to the system tray without needing two processes.
Anthony Liguori Oct. 26, 2009, 3:49 p.m. UTC | #17
Avi Kivity wrote:
> On 10/26/2009 05:04 PM, Anthony Liguori wrote:
>>> Maybe slightly less than 100%.  I meant a native GUI in the same 
>>> process as qemu, but talking to QObjects through a scripting language.
>>
>>
>> The trouble here is that if you want to support being able to close 
>> the gui and open it again without killing the guest, you need the 
>> guest to live in a separate process.
>>
>
> Many applications minimize to the system tray without needing two 
> processes.

Minimizing or hiding the window are different use cases.  Now, I'm not 
100% convinced this use-case is absolutely required but historically, 
it's always come up in discussions of improving the qemu gui.

Imagine the following:

A user starts a VM at a physical box.  Everythings fine but he wants to 
return to his workstation so he closes the window.  He goes back to his 
workstation and connects to a VNC server (on a different X server).  He 
wants to now bring up the guest's display.

This cannot be achieved with a gui in the same process as qemu.  Is it 
necessary to support?  I don't know.

I'd love to just replace the SDL display with GTK + Cairo.  I'm even 
somewhat inclined to suggest linking to python so that the gui can be 
written in python...

Regards,

Anthony Liguori
Avi Kivity Oct. 26, 2009, 4:08 p.m. UTC | #18
On 10/26/2009 05:49 PM, Anthony Liguori wrote:
>> Many applications minimize to the system tray without needing two 
>> processes.
>
>
> Minimizing or hiding the window are different use cases.  Now, I'm not 
> 100% convinced this use-case is absolutely required but historically, 
> it's always come up in discussions of improving the qemu gui.
>
> Imagine the following:
>
> A user starts a VM at a physical box.  Everythings fine but he wants 
> to return to his workstation so he closes the window.  He goes back to 
> his workstation and connects to a VNC server (on a different X 
> server).  He wants to now bring up the guest's display.

Users don't have boxes.  They have computers.  They don't want to open 
VNC clients and type in meaningless numerical addresses.  They do want 
GUIs which fit with the OSes theme, cut'n'paste, printing, and shared 
storage, all easily configurable.

(and before someone tells me I don't know what users want - users don't 
read qemu-devel, either).

> This cannot be achieved with a gui in the same process as qemu.  Is it 
> necessary to support?  I don't know.

In the priority list this is about 3000 places below having nice buttons 
to eject and insert a CDROM.  A user with a "box" would probably want to 
run the guest on a server (and use vnc, etc.).

> I'd love to just replace the SDL display with GTK + Cairo.  I'm even 
> somewhat inclined to suggest linking to python so that the gui can be 
> written in python...

Best would be to just export a QObject binding to scripting languages, 
which could then be used to implement GUIs outside the qemu source 
base.  The only tricky part is how to deal with the display.  Can we 
expose the display as a special QDict?
Anthony Liguori Oct. 26, 2009, 4:17 p.m. UTC | #19
Avi Kivity wrote:
> On 10/26/2009 05:49 PM, Anthony Liguori wrote:
>> A user starts a VM at a physical box.  Everythings fine but he wants 
>> to return to his workstation so he closes the window.  He goes back 
>> to his workstation and connects to a VNC server (on a different X 
>> server).  He wants to now bring up the guest's display.
>
> Users don't have boxes.  They have computers.  They don't want to open 
> VNC clients and type in meaningless numerical addresses.  They do want 
> GUIs which fit with the OSes theme, cut'n'paste, printing, and shared 
> storage, all easily configurable.

You misunderstood.  The VNC session is to the users remote desktop.  But 
drop VNC for a minute, this is the same thing as just closing the window 
because the VM runs all day and you don't need to see it's display.  
Like I said, I've never been convinced that this is critical but it's 
always been a very vocal argument against more GUI functionality.

>> This cannot be achieved with a gui in the same process as qemu.  Is 
>> it necessary to support?  I don't know.
>
> In the priority list this is about 3000 places below having nice 
> buttons to eject and insert a CDROM.  A user with a "box" would 
> probably want to run the guest on a server (and use vnc, etc.).

I do agree with you.

>> I'd love to just replace the SDL display with GTK + Cairo.  I'm even 
>> somewhat inclined to suggest linking to python so that the gui can be 
>> written in python...
>
> Best would be to just export a QObject binding to scripting languages, 
> which could then be used to implement GUIs outside the qemu source 
> base.  The only tricky part is how to deal with the display.  Can we 
> expose the display as a special QDict?

I'd expose the display as a GTKWidget derivative.  We would load a 
python program and it could instantiate the widget because we've already 
loaded it.  I wouldn't bother with QObject at all.  Just setup an easy 
way to use QMP from within Python using the natural python types.

The trick only real trick is that the python script has to be launched 
from a separate thread because Python isn't asynchronous and has a big 
lock at the binding level.  But it works well if you have a socketpair 
with QMP that is used from the Python thread.

Regards,

Anthony Liguori
Gerd Hoffmann Oct. 27, 2009, 9:11 a.m. UTC | #20
On 10/26/09 17:08, Avi Kivity wrote:
>> A user starts a VM at a physical box. Everythings fine but he wants to
>> return to his workstation so he closes the window. He goes back to his
>> workstation and connects to a VNC server (on a different X server). He
>> wants to now bring up the guest's display.
>
> Users don't have boxes. They have computers. They don't want to open VNC
> clients and type in meaningless numerical addresses.

A qemu gui can easily hide that it actually uses vnc.  The only thing 
needed is a connection to the monitor (you'll need that anyway to have 
your fancy buttons do anything useful).  The GUI can do 'info vnc' to 
figure how to connect to the vnc server then.

> They do want GUIs
> which fit with the OSes theme, cut'n'paste, printing, and shared
> storage, all easily configurable.

You mean something like virt-manager?

BTW: you can quit and restart virt-manager while your VMs keep running.

>> This cannot be achieved with a gui in the same process as qemu. Is it
>> necessary to support? I don't know.
>
> In the priority list this is about 3000 places below having nice buttons
> to eject and insert a CDROM. A user with a "box" would probably want to
> run the guest on a server (and use vnc, etc.).

Focusing on the users needs *only* doesn't fly.  You want have users and 
hackers use the same thing, otherwise you'll have a hard time finding 
developers for the GUI.  Which in turn means placing the GUI into a 
separate process (which may even run on another machine) is a must-have.

cheers,
   Gerd
Avi Kivity Oct. 27, 2009, 9:28 a.m. UTC | #21
On 10/27/2009 11:11 AM, Gerd Hoffmann wrote:
> On 10/26/09 17:08, Avi Kivity wrote:
>>> A user starts a VM at a physical box. Everythings fine but he wants to
>>> return to his workstation so he closes the window. He goes back to his
>>> workstation and connects to a VNC server (on a different X server). He
>>> wants to now bring up the guest's display.
>>
>> Users don't have boxes. They have computers. They don't want to open VNC
>> clients and type in meaningless numerical addresses.
>
> A qemu gui can easily hide that it actually uses vnc.  The only thing 
> needed is a connection to the monitor (you'll need that anyway to have 
> your fancy buttons do anything useful).  The GUI can do 'info vnc' to 
> figure how to connect to the vnc server then.

It can't hide the inefficiency introduced by vnc.  It doesn't matter for 
cirrus, but it will matter with more powerful vgpus.

Even if you tunnel gpu commands on vnc, you still have to be able to 
reconstruct your state on client disconnect.  With a native client, a 
disconnect is not posssible, so we can rely on client rendering.

>> They do want GUIs
>> which fit with the OSes theme, cut'n'paste, printing, and shared
>> storage, all easily configurable.
>
> You mean something like virt-manager?

Like virt-manager, but with all the things I mentioned.

> BTW: you can quit and restart virt-manager while your VMs keep running.

Sure, since we don't much care about graphics performance.

>>> This cannot be achieved with a gui in the same process as qemu. Is it
>>> necessary to support? I don't know.
>>
>> In the priority list this is about 3000 places below having nice buttons
>> to eject and insert a CDROM. A user with a "box" would probably want to
>> run the guest on a server (and use vnc, etc.).
>
> Focusing on the users needs *only* doesn't fly.  You want have users 
> and hackers use the same thing, otherwise you'll have a hard time 
> finding developers for the GUI. 

If that's so, we're doomed.  If the only itches scratched are 
deveopers', real users will be left out in the cold (or rather, in the 
evil clutches of those who will scratch their itches).

> Which in turn means placing the GUI into a separate process (which may 
> even run on another machine) is a must-have.

I don't see how this follows.  How does catering to 
developers/power-users imply that can't we have an in-process GUI?

We'll still have vnc for server deployments.
diff mbox

Patch

diff --git a/monitor.c b/monitor.c
index 2566f4a..f8e2844 100644
--- a/monitor.c
+++ b/monitor.c
@@ -107,6 +107,15 @@  struct Monitor {
     QLIST_ENTRY(Monitor) entry;
 };
 
+typedef struct MonitorMacro {
+    QTAILQ_ENTRY(MonitorMacro) entry;
+    const char *name;
+    const char *command_line;
+} MonitorMacro;
+
+static QTAILQ_HEAD(monitor_macros, MonitorMacro) monitor_macros = 
+    QTAILQ_HEAD_INITIALIZER(monitor_macros);
+
 static QLIST_HEAD(mon_list, Monitor) mon_list;
 
 static const mon_cmd_t mon_cmds[];
@@ -1909,6 +1918,25 @@  static void do_closefd(Monitor *mon, const QDict *qdict)
                    fdname);
 }
 
+static void do_macro_add(Monitor *mon, const QDict *qdict)
+{
+    MonitorMacro *macro;
+
+    macro = qemu_mallocz(sizeof(*macro));
+    macro->name = qemu_strdup(qdict_get_str(qdict, "name"));
+    macro->command_line = qemu_strdup(qdict_get_str(qdict, "command"));
+
+    QTAILQ_INSERT_TAIL(&monitor_macros, macro, entry);
+}
+
+static void do_macro_list(Monitor *mon, const QDict *qdict)
+{
+    MonitorMacro *macro;
+
+    QTAILQ_FOREACH(macro, &monitor_macros, entry)
+        monitor_printf(mon, "%s: \"%s\"\n", macro->name, macro->command_line);
+}
+
 static void do_loadvm(Monitor *mon, const QDict *qdict)
 {
     int saved_vm_running  = vm_running;
@@ -2902,6 +2930,45 @@  static char *key_get_info(const char *type, char **key)
     return ++p;
 }
 
+static const mon_cmd_t *find_command(const char *cmdname)
+{
+    const mon_cmd_t *cmd;
+
+    /* find the command */
+    for (cmd = mon_cmds; cmd->name != NULL; cmd++) {
+        if (compare_cmd(cmdname, cmd->name))
+            return cmd;
+    }
+
+    return NULL;
+}
+
+static const mon_cmd_t *find_macro(char *cmdname, size_t len, const char **pos)
+{
+    const char *p;
+    MonitorMacro *macro;
+    const mon_cmd_t *cmd;
+
+    QTAILQ_FOREACH(macro, &monitor_macros, entry) {
+        if (strcmp(macro->name, cmdname) == 0)
+            break;
+    }
+
+    if (!macro)
+        return NULL;
+
+    p = get_command_name(macro->command_line, cmdname, len);
+    if (!p)
+        return NULL;
+
+    cmd = find_command(cmdname);
+    if (!cmd)
+        return NULL;
+
+    *pos = p;
+    return cmd;
+}
+
 static int default_fmt_format = 'x';
 static int default_fmt_size = 4;
 
@@ -2927,15 +2994,13 @@  static const mon_cmd_t *monitor_parse_command(Monitor *mon,
     if (!p)
         return NULL;
 
-    /* find the command */
-    for(cmd = mon_cmds; cmd->name != NULL; cmd++) {
-        if (compare_cmd(cmdname, cmd->name))
-            break;
-    }
-
-    if (cmd->name == NULL) {
-        monitor_printf(mon, "unknown command: '%s'\n", cmdname);
-        return NULL;
+    cmd = find_macro(cmdname, sizeof(cmdname), &p);
+    if (!cmd) {
+        cmd = find_command(cmdname);
+        if (!cmd) {
+            monitor_printf(mon, "unknown command: '%s'\n", cmdname);
+            return NULL;
+        }
     }
 
     /* parse the parameters */
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index 29999c6..37561be 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -1031,6 +1031,30 @@  Close the file descriptor previously assigned to @var{fdname} using the
 used by another monitor command.
 ETEXI
 
+    {
+        .name       = "macro_add",
+        .args_type  = "name:s,command:s",
+        .params     = "name command",
+        .help       = "add a new monitor macro",
+        .mhandler.cmd = do_macro_add,
+    },
+
+STEXI
+@item macro_add @var{name} @var{command}
+ETEXI
+
+    {
+        .name       = "macro_list",
+        .args_type  = "",
+        .params     = "",
+        .help       = "list monitor macros",
+        .mhandler.cmd = do_macro_list,
+    },
+
+STEXI
+@item macro_list
+ETEXI
+
 STEXI
 @end table
 ETEXI