RE: Why pass pt_regs throughout the input system?

[Dmitry Torokhov <dtor_core@ameritech.net>]

> On Wed, 12 May 2004 11:50:26 -0700 (PDT)
> Dmitry Torokhov <dtor_core@ameritech.net> wrote:
> 
> > As far as multiple keyboards issue going - SysRq is a debug tool and
> > I relly do not see you hitting SysRq on the two keyboards at the very
> > same time to mess up the call traces.
> 
> Maybe to get two backtraces on two different cpus?
> Be creative :-)

Set CPU affinity to route IRQ to a specific CPU? :)

> 
> > Anyway, my "problem" is the following: SysRq register dump and call
> > trace require keyboard.c event handler to be caled from hard interrupt
> > context which is not always feasible.
> 
> USB handles this fine, and I seem to remember it does use tasklets.
> You can save the pt_regs value at hardware interrupt and pass that
> in during the tasklet run perhaps?

I looked through the USB and unless I miss something it does not use
tasklets there. Also, even if I save the registers in IRQ context and
pass it to tasklet I do not see how I can reconstruct the call trace -
tasklet execution can be passed to ksoftirqd and executed with
completely different stack. The output would lie horribly.

Also, while I was looking at USB implementation - it also drags pt_regs
pointer everywhere for SysRq handling only and no other benefits. The
data is foreign and unneeded for both input and USB systems.

What is the objection to printing the trace at do_IRQ time and having
SysRq merely post a request instead of executing it?

Thank you,

Dmitry