Messages in this thread | | | From | Dmitry Torokhov <> | Subject | Re: [RFC] Changing SysRq - show registers handling | Date | Thu, 3 Jun 2004 02:27:22 -0500 |
| |
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 = ®s; > > > ... > > > *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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |