Patchwork Use clean shutdown request for ctrl-a x

login
register
mail settings
Submitter Fabien Chouteau
Date July 3, 2012, 1:38 p.m.
Message ID <1341322722-32691-1-git-send-email-chouteau@adacore.com>
Download mbox | patch
Permalink /patch/168812/
State New
Headers show

Comments

Fabien Chouteau - July 3, 2012, 1:38 p.m.
Signed-off-by: Fabien Chouteau <chouteau@adacore.com>
---
 qemu-char.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Peter Maydell - July 3, 2012, 2 p.m.
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
Paolo Bonzini - July 3, 2012, 2:49 p.m.
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
Fabien Chouteau - July 3, 2012, 3:07 p.m.
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();
}
Kevin Wolf - July 4, 2012, 10:07 a.m.
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
Fabien Chouteau - July 4, 2012, 10:27 a.m.
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".
Kevin Wolf - July 4, 2012, 10:32 a.m.
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
Fabien Chouteau - July 4, 2012, 10:51 a.m.
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,

Patch

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':