Magic SysRq +# in 2.4.9-ac/2.4.10-pre12

[Randy.Dunlap]

(and maybe earlier...)

Simple problems grow...

Keith Owens has already noted one problem in sysrq.c (2.4.10-pre12).

Beginning:

I have an IBM model KB-9910 keyboard.  When I use
Alt+SysRQ+number (number: 0...9) on it to change the
console loglevel, only keys 5 and 6 have the desired
effect.  I used showkey -s to view the scancodes from
the other <number> keys, but showkey didn't display
anything for them.  Any other suggestions?

For now, I'm just using different (non-number) keys
to modify the loglevel.

Anyway, in looking at SysRq loglevel handling in
2.4.9-ac (and 2.4.10-pre12), I see that it has been modified
quite a bit.  Looks extensible, which can be good.
However, looking over it gave me several nagging questions
and problems.

1.  Was this stuff tested?  How ???

It always sets console_loglevel and then restores
console_loglevel from orig_log_level, so Alt+SysRq+#
handling is severely broken.

If someone (Crutcher ?) wants to patch it, that's fine.
If I patched it, I would just add a
  next_loglevel = -1;
at the beginning of __handle_sysrq_nolock() and then
let the loglevel handler(s) set next_loglevel.
If next_loglevel != -1 at the end of __handle_sysrq_nolock(),
set console_loglevel to next_loglevel.

2.  I'd really prefer to see callers use
register_sysrq_key() and unregister_sysrq_key() so that they
can get/use return values, and not the lower-level functions
"__sysrq*" functions that are EXPORTed in sysrq.c.
I don't see a good reason to EXPORT all of these functions.

E.g., arch/ppc64/start/xmon.c calls __sysrq_put_key_op('x', ...).
It doesn't know (and cannot know) whether this call succeeded
or not.

3.  And the sysrq_key_table[] (comments) should end with
w, x, y, z, not with w, x, w, z.

~Randy

You can't do anything without having to do something else first. 
         -- Belefant's Law