Re: [PATCH 5/5] x86/traps: Clean up diagnostics

[Jan Beulich <jbeulich@xxxxxxxx>]

On 22.11.2021 17:26, Andrew Cooper wrote:
> On 22/11/2021 09:08, Jan Beulich wrote:
>> On 19.11.2021 19:21, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -759,21 +759,7 @@ static int nmi_show_execution_state(const struct 
>>> cpu_user_regs *regs, int cpu)
>>>      return 1;
>>>  }
>>>  
>>> -const char *trapstr(unsigned int trapnr)
>>> -{
>>> -    static const char * const 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",
>>> -        "machine check", "simd error", "virtualisation exception"
>>> -    };
>>> -
>>> -    return trapnr < ARRAY_SIZE(strings) ? strings[trapnr] : "???";
>>> -}
>>> -
>>> -static const char *vec_name(unsigned int vec)
>>> +const char *vec_name(unsigned int vec)
>> Is this perhaps too ambiguous a name for a non-static function? 
>> exn_vec_name()
>> at least, maybe?
> 
> "exception" has the same problem that "trap" has.  It's actively
> incorrect naming.

Well, yes, "exception_or_interrupt_name" would be more correct but quite
a bit too long for my taste. In an earlier project I did work on we
used "interruption" to cover everything (including hardware interrupts),
but the abbreviation thereof wouldn't be distinguishable from
"interrupt"'s.

Bottom line - you have my R-b, and the name change was just an extra
consideration.

Jan