| Message ID | 20091022124036.5df991f3@doriath |
|---|---|
| State | New |
| Headers | show |
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
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
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. :)
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?
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
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
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?
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
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
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
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.
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..
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
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.
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
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.
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
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?
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
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
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 --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