sysrq loglevel

[Andy Whitcroft]

It seems that we deliberatly manage the console_loglevel while handling a
sysrq request.  Raising it to 7 to emit the sysrq command header, and then
lower it before processing the command itself.  When booting the kernel
'quiet' this means that we only see the header of the command and not its
output on the console, the whole thing is in dmesg and thereby in syslog
(if it is working).

void __handle_sysrq(int key, struct tty_struct *tty, int check_mask)
[...]
        console_loglevel = 7;
        printk(KERN_INFO "SysRq : ");
[...]
                        printk("%s\n", op_p->action_msg);
                        console_loglevel = orig_log_level;
                        op_p->handler(key, tty);
[...]

Is this intentional?  I can see arguments both ways.  One way to look at
it would be that I asked for the output so I should get it regardless.
The other side might be that consoles can be really slow (serial or
something) and so only outputting it there if logging is enabled
generally is sane.

Obviously we can work round this at the moment using sysrq-7 to up the
loglevel before the command and sysrq-4 after to restore quiet.

What do people think.  If we are happy with the status quo then I will
spin a documentation patch to point out this behaviour and the work
around.  Else I will happily spin a patch to fix it.

Thoughts?

-apw
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/