| Message ID | f284c33d0910180924h13762eebl4f029c9606988dec@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
Mulyadi Santosa wrote: > IMO, it would be faster if we provide keyboard shortcuts that will > stop and resume VM execution right from SDL guest interface, rather > than switching to console monitor first and type "s" or "c" > respectively. > Is this really common of an operation that you would need an escape key for it? Why are you so frequently stopping and continuing a guest? Regards, Anthony Liguori
Hi Anthony... On Tue, Oct 20, 2009 at 5:20 AM, Anthony Liguori <anthony@codemonkey.ws> wrote: > Mulyadi Santosa wrote: >> >> IMO, it would be faster if we provide keyboard shortcuts that will >> stop and resume VM execution right from SDL guest interface, rather >> than switching to console monitor first and type "s" or "c" >> respectively. >> > > Is this really common of an operation that you would need an escape key for > it? > > Why are you so frequently stopping and continuing a guest? Thanks for giving a review. One of the use case is to pause guest at a specific moment relatively fast. For example, I boot a guest and I want to capture at a certain moment when the guest kernel initialize and print something in the screen. As these message scrolls fast, I find it more intuitive if we could just press a key to pause the guest, giving us enough time to capture the display and resume the execution. If we switch to qemu monitor first, most of the time we already lost the moment.
On 10/20/09 05:16, Mulyadi Santosa wrote: > As these message scrolls fast, I find it more intuitive if we could > just press a key to pause the guest, giving us enough time to capture > the display and resume the execution. If we switch to qemu monitor > first, most of the time we already lost the moment. I'd find it more intuitive to setup a serial console in the guest, then simply log everything to a file ... cheers, Gerd
On Tue, Oct 20, 2009 at 10:16:09AM +0700, Mulyadi Santosa wrote: > Hi Anthony... > > On Tue, Oct 20, 2009 at 5:20 AM, Anthony Liguori <anthony@codemonkey.ws> wrote: > > Mulyadi Santosa wrote: > >> > >> IMO, it would be faster if we provide keyboard shortcuts that will > >> stop and resume VM execution right from SDL guest interface, rather > >> than switching to console monitor first and type "s" or "c" > >> respectively. > >> > > > > Is this really common of an operation that you would need an escape key for > > it? > > > > Why are you so frequently stopping and continuing a guest? > > Thanks for giving a review. > > One of the use case is to pause guest at a specific moment relatively > fast. For example, I boot a guest and I want to capture at a certain > moment when the guest kernel initialize and print something in the > screen. > > As these message scrolls fast, I find it more intuitive if we could > just press a key to pause the guest, giving us enough time to capture > the display and resume the execution. If we switch to qemu monitor > first, most of the time we already lost the moment. If its too slow to switch to the monitor virtual console,then don't configure the monitor in that way. Set it up to be on stdio, or one of the other backends. That lets you have both the monitor & SDL display visible at the same time & would be just as fast to type in 'stop' at the appropriate time. If its kernel text output you need to see then a serial port + logging is the best option here as Gerd suggests. If its video output you need to see, then VNC along with something like vnc2swf which will record the entire VNC data stream to a movie, which you can then play back and easily pause at any point. Regards, Daniel
Am 20.10.2009 00:20, schrieb Anthony Liguori: > Mulyadi Santosa wrote: >> IMO, it would be faster if we provide keyboard shortcuts that will >> stop and resume VM execution right from SDL guest interface, rather >> than switching to console monitor first and type "s" or "c" >> respectively. >> > > Is this really common of an operation that you would need an escape key > for it? > > Why are you so frequently stopping and continuing a guest? Why are you all trying to explain to him that actually he doesn't want to have this feature? I could have used it, too, at times (stop the guest to have enough time to attach gdb, for example). There are other ways to do it (although they are not as simple) and I used them, but that doesn't make this feature less useful. Does it take anything away for you? Or do you have plans to use those keys otherwise? If not, why not add a feature that some might find useful, even though others don't? Kevin
Kevin Wolf wrote: > Am 20.10.2009 00:20, schrieb Anthony Liguori: > >> Mulyadi Santosa wrote: >> >>> IMO, it would be faster if we provide keyboard shortcuts that will >>> stop and resume VM execution right from SDL guest interface, rather >>> than switching to console monitor first and type "s" or "c" >>> respectively. >>> >>> >> Is this really common of an operation that you would need an escape key >> for it? >> >> Why are you so frequently stopping and continuing a guest? >> > > Why are you all trying to explain to him that actually he doesn't want > to have this feature? I could have used it, too, at times (stop the > guest to have enough time to attach gdb, for example). There are other > ways to do it (although they are not as simple) and I used them, but > that doesn't make this feature less useful. > > Does it take anything away for you? Or do you have plans to use those > keys otherwise? If not, why not add a feature that some might find > useful, even though others don't? > There is such a thing as feature bloat. It leads to very confusing behavior for users. It also increases the testing matrix. As it turns out, there's a better way to do what he's looking for that requires no changes. Had we just taken this patch, then that's another feature that has to be tested for SDL whenever there's a change there. It also means there will be differing behavior for VNC so it probably needs to be supported there. But then for something like libvirt, it's not going to expect that something else pauses/starts a VM. Features are not free. They have long term maintenance costs so we should consider whether a feature really offers value. Regards, Anthony Liguori
On Tue, Oct 20, 2009 at 12:40:08PM +0200, Kevin Wolf wrote: > Am 20.10.2009 00:20, schrieb Anthony Liguori: > > Mulyadi Santosa wrote: > >> IMO, it would be faster if we provide keyboard shortcuts that will > >> stop and resume VM execution right from SDL guest interface, rather > >> than switching to console monitor first and type "s" or "c" > >> respectively. > >> > > > > Is this really common of an operation that you would need an escape key > > for it? > > > > Why are you so frequently stopping and continuing a guest? > > Why are you all trying to explain to him that actually he doesn't want > to have this feature? I could have used it, too, at times (stop the > guest to have enough time to attach gdb, for example). There are other > ways to do it (although they are not as simple) and I used them, but > that doesn't make this feature less useful. > > Does it take anything away for you? Or do you have plans to use those > keys otherwise? If not, why not add a feature that some might find > useful, even though others don't? The problem with adding lots of magic key-sequences, is that the more you add, the more likely they are to clash with something that the guest OS wants to use. You may make this use case work, but break someone else's use case. Thus, IMHO, magic key sequences should be kept to the bare minimum neccessary to access functionality for which there is no other viable access method. Regards, Daniel
Hi... On Wed, Oct 21, 2009 at 12:08 AM, Daniel P. Berrange <berrange@redhat.com> wrote: > The problem with adding lots of magic key-sequences, is that the more > you add, the more likely they are to clash with something that the > guest OS wants to use. You may make this use case work, but break > someone else's use case. Thus, IMHO, magic key sequences should be kept > to the bare minimum neccessary to access functionality for which there > is no other viable access method. Thanks for the insights from all of you. The rule "to keep the magic keys at the bare minimum" is something I fairly agree. So probably in maintenance and development robustness's point of view, this patch should just live outside of main tree... well unless there are lot of supporter
Am 20.10.2009 19:08, schrieb Daniel P. Berrange: > On Tue, Oct 20, 2009 at 12:40:08PM +0200, Kevin Wolf wrote: >> Am 20.10.2009 00:20, schrieb Anthony Liguori: >>> Mulyadi Santosa wrote: >>>> IMO, it would be faster if we provide keyboard shortcuts that will >>>> stop and resume VM execution right from SDL guest interface, rather >>>> than switching to console monitor first and type "s" or "c" >>>> respectively. >>>> >>> >>> Is this really common of an operation that you would need an escape key >>> for it? >>> >>> Why are you so frequently stopping and continuing a guest? >> >> Why are you all trying to explain to him that actually he doesn't want >> to have this feature? I could have used it, too, at times (stop the >> guest to have enough time to attach gdb, for example). There are other >> ways to do it (although they are not as simple) and I used them, but >> that doesn't make this feature less useful. >> >> Does it take anything away for you? Or do you have plans to use those >> keys otherwise? If not, why not add a feature that some might find >> useful, even though others don't? > > The problem with adding lots of magic key-sequences, is that the more > you add, the more likely they are to clash with something that the > guest OS wants to use. You may make this use case work, but break > someone else's use case. Thus, IMHO, magic key sequences should be kept > to the bare minimum neccessary to access functionality for which there > is no other viable access method. Ok, you have a point there. But why do we have key sequences for fullscreen and resizing the SDL window back to its original size then? Both are things that could be accessed through monitor commands as well. And you don't need the right timing for resizing the window - unlike stopping the VM. So I would be really happy with swapping those for a "stop VM" shortcut. Kevin
On Wed, Oct 21, 2009 at 5:27 AM, Kevin Wolf <kwolf@redhat.com> wrote: > Am 20.10.2009 19:08, schrieb Daniel P. Berrange: >> On Tue, Oct 20, 2009 at 12:40:08PM +0200, Kevin Wolf wrote: >>> Am 20.10.2009 00:20, schrieb Anthony Liguori: >>>> Mulyadi Santosa wrote: >>>>> IMO, it would be faster if we provide keyboard shortcuts that will >>>>> stop and resume VM execution right from SDL guest interface, rather >>>>> than switching to console monitor first and type "s" or "c" >>>>> respectively. >>>>> >>>> >>>> Is this really common of an operation that you would need an escape key >>>> for it? >>>> >>>> Why are you so frequently stopping and continuing a guest? >>> >>> Why are you all trying to explain to him that actually he doesn't want >>> to have this feature? I could have used it, too, at times (stop the >>> guest to have enough time to attach gdb, for example). There are other >>> ways to do it (although they are not as simple) and I used them, but >>> that doesn't make this feature less useful. >>> >>> Does it take anything away for you? Or do you have plans to use those >>> keys otherwise? If not, why not add a feature that some might find >>> useful, even though others don't? >> >> The problem with adding lots of magic key-sequences, is that the more >> you add, the more likely they are to clash with something that the >> guest OS wants to use. You may make this use case work, but break >> someone else's use case. Thus, IMHO, magic key sequences should be kept >> to the bare minimum neccessary to access functionality for which there >> is no other viable access method. > > Ok, you have a point there. But why do we have key sequences for > fullscreen and resizing the SDL window back to its original size then? > Both are things that could be accessed through monitor commands as well. > And you don't need the right timing for resizing the window - unlike > stopping the VM. So I would be really happy with swapping those for a > "stop VM" shortcut. Why don't we provide a mechanism to make a macro out of a sequence of monitor commands, and let the user assign whatever he wants out of that?
On Wed, Oct 21, 2009 at 8:52 PM, Glauber Costa <glommer@gmail.com> wrote: > Why don't we provide a mechanism to make a macro out of a sequence of > monitor commands, and let the user assign whatever he wants out of that? Presto! never thought about that....what are we supposed to do in order to provide such mechanism? Who knows, perhaps I can lend a hand (again) here....
On Wed, Oct 21, 2009 at 2:04 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote: > On Wed, Oct 21, 2009 at 8:52 PM, Glauber Costa <glommer@gmail.com> wrote: >> Why don't we provide a mechanism to make a macro out of a sequence of >> monitor commands, and let the user assign whatever he wants out of that? > > Presto! never thought about that....what are we supposed to do in > order to provide such mechanism? Who knows, perhaps I can lend a hand > (again) here.... You can provide a monitor command to do that something in the lines of: - add_macro <key> <command_list> - remove_macro <key> - list_macros then you could keep the assigned keys in a list, and convert the command list to a list of functions and arguments. For compatibility, the current assigned keystrokes would be then converted to default macros, that could be removed, if requested It would be nice if you could find a way to update it on all displays, not only SDL, at once. this requires a little bit more work than what you did, but at least from my point of view, would be a nice feature, and overcome the limitations that people mentioned.
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.
On Wed, Oct 21, 2009 at 2:44 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com> 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. yes, this is what I meant. But notice that this is just a suggestion. The internet is a free country, and if you are indeed implementing this, you are free to add your own spice.
Glauber Costa wrote: > Why don't we provide a mechanism to make a macro out of a sequence of > monitor commands, and let the user assign whatever he wants out of that? > Really? This seems exceedingly complicated to me. Redirecting the kernel output to serial and logging is a considerably better solution. Regards, Anthony Liguori
On Wed, Oct 21, 2009 at 11:55 PM, Anthony Liguori <anthony@codemonkey.ws> wrote: > Really? This seems exceedingly complicated to me. > > Redirecting the kernel output to serial and logging is a considerably better > solution. I'll respectfully consider everybody's thought here....interesting discussion so far though. mean while, if time permits I shall try to improve my work and let's hear what everybody thinks.
On Wed, Oct 21, 2009 at 2:55 PM, Anthony Liguori <anthony@codemonkey.ws> wrote: > Glauber Costa wrote: >> >> Why don't we provide a mechanism to make a macro out of a sequence of >> monitor commands, and let the user assign whatever he wants out of that? >> > > Really? This seems exceedingly complicated to me. > > Redirecting the kernel output to serial and logging is a considerably better > solution. To his specific problem, yes. But this probably don't work so well on some OSes that are less serial friendly. Also, there are valid use cases in which one may want, for example, to pause fast if some graphical event happens, which is an extension of what he mentioned initially.
Glauber Costa wrote: > On Wed, Oct 21, 2009 at 2:55 PM, Anthony Liguori <anthony@codemonkey.ws> wrote: > >> Glauber Costa wrote: >> >>> Why don't we provide a mechanism to make a macro out of a sequence of >>> monitor commands, and let the user assign whatever he wants out of that? >>> >>> >> Really? This seems exceedingly complicated to me. >> >> Redirecting the kernel output to serial and logging is a considerably better >> solution. >> > To his specific problem, yes. > > But this probably don't work so well on some OSes that are less serial friendly. > Also, there are valid use cases in which one may want, for example, to pause > fast if some graphical event happens, which is an extension of what he mentioned > initially. > Then type "stop" in the monitor and hit enter when you need to. Or, write a simple VNC client using gtk-vnc that can have any sort of crazy key sequences you want. Regards, Anthony Liguori
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. 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... Syntax idea comes to mind is: - Add ";" as command separator. - add_macro <name> <command-string> - remove_macro <name> - list_macros - add_key key <key> <command-string> - remove_key <key> <command-string> - list_keys (If I were starting from nothing it'd be macro_add, macro_remove etc. or maybe "macro add", but the above seems more consistent with the existing monitor) -- Jamie
Am 21.10.2009 20:08, schrieb Anthony Liguori: > Glauber Costa wrote: >> On Wed, Oct 21, 2009 at 2:55 PM, Anthony Liguori <anthony@codemonkey.ws> wrote: >> >>> Glauber Costa wrote: >>> >>>> Why don't we provide a mechanism to make a macro out of a sequence of >>>> monitor commands, and let the user assign whatever he wants out of that? >>>> >>>> >>> Really? This seems exceedingly complicated to me. >>> >>> Redirecting the kernel output to serial and logging is a considerably better >>> solution. >>> >> To his specific problem, yes. >> >> But this probably don't work so well on some OSes that are less serial friendly. >> Also, there are valid use cases in which one may want, for example, to pause >> fast if some graphical event happens, which is an extension of what he mentioned >> initially. >> > > Then type "stop" in the monitor and hit enter when you need to. Or, > write a simple VNC client using gtk-vnc that can have any sort of crazy > key sequences you want. Having two different consoles at the same time is easy. Guest graphics in the SDL window, serial console on stdio. And now I need to add a monitor. Means that I need to start using named pipes or TCP connections or something. And I need to arrange the windows so that I can see qemu's SDL window and the shell with my netcat (or whatever) gets the enter key I hit. Yes, it's possible, but it's not nice. I like Jamie's suggestion for macros. Kevin
--- sdl.c.bak 2009-08-02 16:00:28.000000000 +0700 +++ sdl.c 2009-10-18 22:53:59.000000000 +0700 @@ -440,6 +440,7 @@ static void sdl_refresh(DisplayState *ds if (gui_key_modifier_pressed) { int keycode; keycode = sdl_keyevent_to_keycode(&ev->key); + //fprintf(stderr,"scan code of key pressed is %d\n",keycode); switch(keycode) { case 0x21: /* 'f' key on US keyboard */
IMO, it would be faster if we provide keyboard shortcuts that will stop and resume VM execution right from SDL guest interface, rather than switching to console monitor first and type "s" or "c" respectively. Note: I simply skip checking the keys in encrypted block devices when resuming the VM. Not sure whether we really need it or not. Signed-off-by: Mulyadi Santosa <mulyadi.santosa@gmail.com> sdl.c | 9 +++++++++ 1 file changed, 9 insertions(+) toggle_full_screen(ds); @@ -456,6 +457,14 @@ static void sdl_refresh(DisplayState *ds } gui_keysym = 1; break; + case 0x1f: /* 's' key -- stopping VM */ + vm_stop(16); /* 16 is EXCP_INTERRUPT */ + gui_keysym = 1; + break; + case 0x2e: /* 'c' key -- resuming VM */ + vm_start(); /* we skip checking encrypted block drive */ + gui_keysym = 1; + break; default: break; }