Re: [RFC] Changing SysRq - show registers handling

From: Dmitry Torokhov
Date: Thu Jun 03 2004 - 02:29:23 EST


On Thursday 03 June 2004 02:18 am, Andrew Morton wrote:
> Dmitry Torokhov <dtor_core@xxxxxxxxxxxxx> wrote:
> >
> > > do_IRQ(...)
> > > {
> > > ...
> > > struct pt_regs **cpu_regs_slot = __get_cpu_var(global_irq_regs);
> > > struct pt_regs *save = *cpu_regs_slot;
> > > *cpu_regs_slot = &regs;
> > > ...
> > > *cpu_regs_slot = save;
> > > }
> > >
> > > And to teach the sysrq code to grab *__get_cpu_var(global_irq_regs).
> >
> > Ok, so by making it a tad slower you can keep the old semantics - printing
> > registers right when keyboard interrupt is processed instead of waiting till
> > the next one arrives.
> >
> > Hmm... the path is pretty hot, I am not sure what is best.
>
> Well bear in mind that we can then rip all the pt_regs passing out from
> everywhere, so as long as you edit every IRQ handler in the kernel it's a
> net win ;)

Will you let me? :) USB and serio will at least not mess anyone else...

>
> I _think_ it'll work - as long as all architectures go through a common
> dispatch function like do_IRQ(), which surely they do. The above code
> could be an arch-neutral inline actually.
>
> I'm not sure what's best really. But something this general is more
> attractive than something which is purely for sysrs-T.
>

I don't like the requirement of SysRq request processing being in hard
interrupt handler - that excludes uinput-generated events and precludes
moving keyboard handling to a tasklet for example.

--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/