mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* Why pass pt_regs throughout the input system?
@ 2004-05-12  4:04 Dmitry Torokhov
  2004-05-12  8:40 ` Vojtech Pavlik
  0 siblings, 1 reply; 6+ messages in thread
From: Dmitry Torokhov @ 2004-05-12  4:04 UTC (permalink / raw)
  To: linux-kernel; +Cc: Vojtech Pavlik

Hi,

I have a question - why do we have to pass pt_regs structure throughout
entire input system? As far as I can tell it is a snapshot of all registers
that is done at the keyboard interrupt time and it is not used for anything
but for displaying this data when requested by SysRq.

Would it be wrong to save it by the hardware driver at interrupt time into a
structure accessible by keyboard.c? I do not think it matters if the data
shown by SysRq comes from interrupt other than one that serves keyboard...

Although it is somewhat a domain violation I do not think it is worse than
fattening interface to pass information that is not needed by most of its
users.  

-- 
Dmitry

^ permalink raw reply	[flat|nested] 6+ messages in thread
* RE: Why pass pt_regs throughout the input system?
@ 2004-05-12 18:50 Dmitry Torokhov
  2004-05-12 19:10 ` David S. Miller
  0 siblings, 1 reply; 6+ messages in thread
From: Dmitry Torokhov @ 2004-05-12 18:50 UTC (permalink / raw)
  To: davem; +Cc: linux-kernel, vojtech

Hi David,

First off sorry for breaking the thread but I am insteresed in the
topic and writing this mail via a web-based interface.

> On Wed, 12 May 2004 10:40:56 +0200
> Vojtech Pavlik <vojtech@suse.cz> wrote:
> 
> > Ask David S. Miller for details - I think the problem was with
> > simultaneous invocation of multiple pt_regs printouts.
> 
> That's correct, if i'm using multiple keyboards (say one i8042 based
> and one USB based) in order to get fancy debugging dumps, any scheme
> that saves away info at interrupt time simply will be inaccurate and
> not work.

I understand that but is the keyboard interrupt data is the most
interesting? I thought that the "middle" part of the call trace is
much more important as it shows what is happening to the system.
Or am I missing something?

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.

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. If it is called from a tasklet
even if I save registers I will not be able to reconstruct the call
trace. I wonder if the following change is acceptable:

- SysRq posts a request for registers and call trace to be printed
- When next interrupt comes in (any interrupt) do_IRQ will check the
  flag and print registes and the trace. The check can be made pretty
  cheap as we can coarsely check if it is set without any locks and
  only if it is set do the fine-grained locking stuff so it processed
  only one. If we miss the flag in one interrupt it is not a big deal
  as it will be noticed when the next interrupt arrives.

This is assuming that we are actually interested in what system was
doing _besides_ processing keyboard interrupt.

Dmitry




^ permalink raw reply	[flat|nested] 6+ messages in thread
* RE: Why pass pt_regs throughout the input system?
@ 2004-05-12 20:01 Dmitry Torokhov
  0 siblings, 0 replies; 6+ messages in thread
From: Dmitry Torokhov @ 2004-05-12 20:01 UTC (permalink / raw)
  To: davem; +Cc: linux-kernel, vojtech

> 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


^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-05-12 20:28 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-05-12  4:04 Why pass pt_regs throughout the input system? Dmitry Torokhov
2004-05-12  8:40 ` Vojtech Pavlik
2004-05-12 18:15   ` David S. Miller
2004-05-12 18:50 Dmitry Torokhov
2004-05-12 19:10 ` David S. Miller
2004-05-12 20:01 Dmitry Torokhov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®