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
