Re: [RFC] Changing SysRq - show registers handling

[Dmitry Torokhov <dtor_core@ameritech.net>]

On Thursday 03 June 2004 02:18 am, Andrew Morton wrote:
> Dmitry Torokhov <dtor_core@ameritech.net> 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