| Message ID | 1341322722-32691-1-git-send-email-chouteau@adacore.com |
|---|---|
| State | New |
| Headers | show |
On 3 July 2012 14:38, Fabien Chouteau <chouteau@adacore.com> wrote: > > Signed-off-by: Fabien Chouteau <chouteau@adacore.com> > --- > qemu-char.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/qemu-char.c b/qemu-char.c > index c2aaaee..1f43c95 100644 > --- a/qemu-char.c > +++ b/qemu-char.c > @@ -353,7 +353,7 @@ static int mux_proc_byte(CharDriverState *chr, MuxDriver *d, int ch) > { > const char *term = "QEMU: Terminated\n\r"; > chr->chr_write(chr,(uint8_t *)term,strlen(term)); > - exit(0); > + qemu_system_shutdown_request(); > break; > } > case 's': > -- > 1.7.9.5 I was just talking on #qemu this morning about the equivalent question of whether the ARM semihosting exit function ought to be doing a qemu_system_shutdown_request rather than a plain exit()... The interesting question for the qemu-char case is whether the code that feeds this magic byte to us is expecting it to have immediate effect or is happy to continue execution and let us shut down with a slight delay. -- PMM
Il 03/07/2012 16:00, Peter Maydell ha scritto: > I was just talking on #qemu this morning about the equivalent question > of whether the ARM semihosting exit function ought to be doing a > qemu_system_shutdown_request rather than a plain exit()... > > The interesting question for the qemu-char case is whether the code that > feeds this magic byte to us is expecting it to have immediate effect > or is happy to continue execution and let us shut down with a slight > delay. And also whether it is supposed to obey -no-shutdown... Paolo
On 07/03/2012 04:49 PM, Paolo Bonzini wrote: > Il 03/07/2012 16:00, Peter Maydell ha scritto: >> I was just talking on #qemu this morning about the equivalent question >> of whether the ARM semihosting exit function ought to be doing a >> qemu_system_shutdown_request rather than a plain exit()... >> >> The interesting question for the qemu-char case is whether the code that >> feeds this magic byte to us is expecting it to have immediate effect >> or is happy to continue execution and let us shut down with a slight >> delay. > > And also whether it is supposed to obey -no-shutdown... I didn't know this option... My goal is to make ctrl-a x to close Qemu in a clean way. The current exit(0) skips a lot of cleanup/close functions, for example in block drivers. We can create a new shutdown function that will override the -no-shutdown option to keep a consistent behavior with ctrl-a x. void qemu_system_force_shutdown(void) { no_shutdown = 0; qemu_system_shutdown_request(); }
Am 03.07.2012 17:07, schrieb Fabien Chouteau: > On 07/03/2012 04:49 PM, Paolo Bonzini wrote: >> Il 03/07/2012 16:00, Peter Maydell ha scritto: >>> I was just talking on #qemu this morning about the equivalent question >>> of whether the ARM semihosting exit function ought to be doing a >>> qemu_system_shutdown_request rather than a plain exit()... >>> >>> The interesting question for the qemu-char case is whether the code that >>> feeds this magic byte to us is expecting it to have immediate effect >>> or is happy to continue execution and let us shut down with a slight >>> delay. >> >> And also whether it is supposed to obey -no-shutdown... > > I didn't know this option... > > My goal is to make ctrl-a x to close Qemu in a clean way. > The current exit(0) skips a lot of cleanup/close functions, for > example in block drivers. > > We can create a new shutdown function that will override the > -no-shutdown option to keep a consistent behavior with ctrl-a x. > > void qemu_system_force_shutdown(void) > { > no_shutdown = 0; > qemu_system_shutdown_request(); > } The same thing already exists in qemu_system_killed(). It could use the same new function if you added it. Or you could reuse the existing code in the ctrl-a x handler by sending SIGTERM. Kevin
On 07/04/2012 12:07 PM, Kevin Wolf wrote: > Am 03.07.2012 17:07, schrieb Fabien Chouteau: >> On 07/03/2012 04:49 PM, Paolo Bonzini wrote: >>> Il 03/07/2012 16:00, Peter Maydell ha scritto: >>>> I was just talking on #qemu this morning about the equivalent question >>>> of whether the ARM semihosting exit function ought to be doing a >>>> qemu_system_shutdown_request rather than a plain exit()... >>>> >>>> The interesting question for the qemu-char case is whether the code that >>>> feeds this magic byte to us is expecting it to have immediate effect >>>> or is happy to continue execution and let us shut down with a slight >>>> delay. >>> >>> And also whether it is supposed to obey -no-shutdown... >> >> I didn't know this option... >> >> My goal is to make ctrl-a x to close Qemu in a clean way. >> The current exit(0) skips a lot of cleanup/close functions, for >> example in block drivers. >> >> We can create a new shutdown function that will override the >> -no-shutdown option to keep a consistent behavior with ctrl-a x. >> >> void qemu_system_force_shutdown(void) >> { >> no_shutdown = 0; >> qemu_system_shutdown_request(); >> } > > The same thing already exists in qemu_system_killed(). It could use the > same new function if you added it. Or you could reuse the existing code > in the ctrl-a x handler by sending SIGTERM. > This function will change the behavior of ctrl-a x by printing "qemu: terminating on signal 0".
Am 04.07.2012 12:27, schrieb Fabien Chouteau: > On 07/04/2012 12:07 PM, Kevin Wolf wrote: >> Am 03.07.2012 17:07, schrieb Fabien Chouteau: >>> On 07/03/2012 04:49 PM, Paolo Bonzini wrote: >>>> Il 03/07/2012 16:00, Peter Maydell ha scritto: >>>>> I was just talking on #qemu this morning about the equivalent question >>>>> of whether the ARM semihosting exit function ought to be doing a >>>>> qemu_system_shutdown_request rather than a plain exit()... >>>>> >>>>> The interesting question for the qemu-char case is whether the code that >>>>> feeds this magic byte to us is expecting it to have immediate effect >>>>> or is happy to continue execution and let us shut down with a slight >>>>> delay. >>>> >>>> And also whether it is supposed to obey -no-shutdown... >>> >>> I didn't know this option... >>> >>> My goal is to make ctrl-a x to close Qemu in a clean way. >>> The current exit(0) skips a lot of cleanup/close functions, for >>> example in block drivers. >>> >>> We can create a new shutdown function that will override the >>> -no-shutdown option to keep a consistent behavior with ctrl-a x. >>> >>> void qemu_system_force_shutdown(void) >>> { >>> no_shutdown = 0; >>> qemu_system_shutdown_request(); >>> } >> >> The same thing already exists in qemu_system_killed(). It could use the >> same new function if you added it. Or you could reuse the existing code >> in the ctrl-a x handler by sending SIGTERM. >> > > This function will change the behavior of ctrl-a x by printing "qemu: > terminating on signal 0". True (on signal 15 actually if you send SIGTERM). So using a new qemu_system_force_shutdown() in both places is fine with me. Kevin
On 07/04/2012 12:32 PM, Kevin Wolf wrote: > Am 04.07.2012 12:27, schrieb Fabien Chouteau: >> On 07/04/2012 12:07 PM, Kevin Wolf wrote: >>> Am 03.07.2012 17:07, schrieb Fabien Chouteau: >>>> On 07/03/2012 04:49 PM, Paolo Bonzini wrote: >>>>> Il 03/07/2012 16:00, Peter Maydell ha scritto: >>>>>> I was just talking on #qemu this morning about the equivalent question >>>>>> of whether the ARM semihosting exit function ought to be doing a >>>>>> qemu_system_shutdown_request rather than a plain exit()... >>>>>> >>>>>> The interesting question for the qemu-char case is whether the code that >>>>>> feeds this magic byte to us is expecting it to have immediate effect >>>>>> or is happy to continue execution and let us shut down with a slight >>>>>> delay. >>>>> >>>>> And also whether it is supposed to obey -no-shutdown... >>>> >>>> I didn't know this option... >>>> >>>> My goal is to make ctrl-a x to close Qemu in a clean way. >>>> The current exit(0) skips a lot of cleanup/close functions, for >>>> example in block drivers. >>>> >>>> We can create a new shutdown function that will override the >>>> -no-shutdown option to keep a consistent behavior with ctrl-a x. >>>> >>>> void qemu_system_force_shutdown(void) >>>> { >>>> no_shutdown = 0; >>>> qemu_system_shutdown_request(); >>>> } >>> >>> The same thing already exists in qemu_system_killed(). It could use the >>> same new function if you added it. Or you could reuse the existing code >>> in the ctrl-a x handler by sending SIGTERM. >>> >> >> This function will change the behavior of ctrl-a x by printing "qemu: >> terminating on signal 0". > > True (on signal 15 actually if you send SIGTERM). So using a new > qemu_system_force_shutdown() in both places is fine with me. > OK, patch on the way... Thanks,
diff --git a/qemu-char.c b/qemu-char.c index c2aaaee..1f43c95 100644 --- a/qemu-char.c +++ b/qemu-char.c @@ -353,7 +353,7 @@ static int mux_proc_byte(CharDriverState *chr, MuxDriver *d, int ch) { const char *term = "QEMU: Terminated\n\r"; chr->chr_write(chr,(uint8_t *)term,strlen(term)); - exit(0); + qemu_system_shutdown_request(); break; } case 's':
Signed-off-by: Fabien Chouteau <chouteau@adacore.com> --- qemu-char.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)