All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH RFC 4/9] x86/misc: Early cleanup
Date: Thu, 15 May 2014 11:38:12 +0100	[thread overview]
Message-ID: <53749914.4090708@citrix.com> (raw)
In-Reply-To: <5374B3C702000078000128C7@mail.emea.novell.com>

On 15/05/14 11:32, Jan Beulich wrote:
>>>> On 15.05.14 at 11:48, <andrew.cooper3@citrix.com> wrote:
>> * machine_restart() disables the watchdog itself, covering itself from other
>>   callers.  Drop superfluous braces and watchdog_disable() from panic().
> Hmm, panic() is common code, and machine_restart()'s property of
> calling watchdog_disable() is x86-specific. I realize that ARM just
> doesn't have a watchdog right now, but do we really want to make
> it a requirement that each watchdog-capable arch does that in
> machine_restart()? Otoh an arch that can tolerate its watchdog
> being disabled over the restart attempt would then not get this
> enforced onto it (in which case only the description above would need
> a little tweaking).

machine_halt() needs just as much watchdog intervention as
machine_restart(), yet that was asymmetric.

I would argue that it is up to the arch to know whether playing with the
watchdog is needed for these things.

>
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -375,21 +375,18 @@ void vcpu_show_execution_state(struct vcpu *v)
>>      vcpu_unpause(v);
>>  }
>>  
>> -static char *trapstr(int trapnr)
>> -{
>> -    static char *strings[] = { 
>> -        "divide error", "debug", "nmi", "bkpt", "overflow", "bounds", 
>> -        "invalid opcode", "device not available", "double fault", 
>> -        "coprocessor segment", "invalid tss", "segment not found", 
>> -        "stack error", "general protection fault", "page fault", 
>> -        "spurious interrupt", "coprocessor error", "alignment check", 
>> +static const char *trapstr(unsigned int trapnr)
>> +{
>> +    static char *strings[] = {
> If you already touch this, and if you already make the function
> return const char *, then this also wants to become const char *const.
>
> Jan
>

Will do.

~Andrew

  reply	other threads:[~2014-05-15 10:38 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-15  9:48 [PATCH RFC 0/9] x86: Improvements to trap handling Andrew Cooper
2014-05-15  9:48 ` [PATCH RFC 1/9] x86/traps: Names for system descriptor types Andrew Cooper
2014-05-15  9:56   ` Andrew Cooper
2014-05-15 10:08   ` Jan Beulich
2014-05-15 10:26     ` Andrew Cooper
2014-05-15 12:10       ` Jan Beulich
2014-05-15  9:48 ` [PATCH RFC 2/9] x86/traps: Make panic and reboot paths safe during early boot Andrew Cooper
2014-05-15 10:19   ` Jan Beulich
2014-05-15 10:53     ` Andrew Cooper
2014-05-15 12:12       ` Jan Beulich
2014-05-15 15:46         ` Andrew Cooper
2014-05-15 15:59           ` Jan Beulich
2014-05-15  9:48 ` [PATCH RFC 3/9] x86/traps: Make the main trap handlers safe for use early during Xen boot Andrew Cooper
2014-05-15 10:20   ` Jan Beulich
2014-05-15  9:48 ` [PATCH RFC 4/9] x86/misc: Early cleanup Andrew Cooper
2014-05-15 10:32   ` Jan Beulich
2014-05-15 10:38     ` Andrew Cooper [this message]
2014-05-15  9:48 ` [PATCH RFC 5/9] x86/traps: Functional prep work Andrew Cooper
2014-05-15 10:36   ` Jan Beulich
2014-05-15 10:45     ` Andrew Cooper
2014-05-15 12:15       ` Jan Beulich
2014-05-15 12:42         ` Andrew Cooper
2014-05-15  9:48 ` [PATCH RFC 6/9] x86/boot: Install trap handlers much earlier on boot Andrew Cooper
2014-05-15 10:53   ` Jan Beulich
2014-05-15 11:05     ` Andrew Cooper
2014-05-15 12:21       ` Jan Beulich
2014-05-15  9:48 ` [PATCH RFC 7/9] x86/boot: Drop pre-C IDT patching Andrew Cooper
2014-05-15  9:48 ` [PATCH RFC 8/9] x86/irqs: Move interrupt-stub generation out of C Andrew Cooper
2014-05-15 13:06   ` Jan Beulich
2014-05-15  9:48 ` [PATCH RFC 9/9] x86/misc: Post cleanup Andrew Cooper
2014-05-15 13:14   ` Jan Beulich
2014-05-15 13:17     ` Andrew Cooper
2014-05-16  8:49 ` [PATCH RFC 0/9] x86: Improvements to trap handling Wu, Feng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53749914.4090708@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=keir@xen.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.