On 14.07.2021 23:03, Bob Eshleman wrote:
> On 7/14/21 2:34 AM, Jan Beulich wrote:
>>> +static inline bool debugger_trap_fatal(
>>> + unsigned int vector, const struct cpu_user_regs *regs)
>>
>> I'm afraid the concept of a vector may not be arch-independent.
>>
>
> The only way I can imagine it not being arch-independent
> is if it is thought of as a trap number or id, instead of
> implying an entry in a vectored trap table. I don't
> really understand this subsystem, so I'm probably missing
> context.
>
> Are you suggesting a rename or a different approach entirely?
I'm suggesting that we shouldn't be claiming something to be an
abstraction when it isn't really. There's exactly one use of
debugger_trap_fatal() outside x86/ after patch 1 of this series:
static void do_debugger_trap_fatal(struct cpu_user_regs *regs)
{
(void)debugger_trap_fatal(0xf001, regs);
...
}
That's very certainly _not_ arch-independent. Hence I'd rather
see some #ifdef-ary added there and the function remaining
x86-specific for the time being, i.e. until such a time when
someone might come forward with a suitable abstraction. Perhaps
(as an alternative to #ifdef-ary) the '%' debug key should be
x86-specific altogether, and perhaps its setup and handling
could be moved into the new debugger.c?
Jan
