What I was trying to suggest is that a new kernel thread was created that
could recompose the messages and push them into the buffer that dmesg reads
(is that /dev/kmsg?). Thus, the old dmesg and anything else would work fine.
However, for internationalization, another (user-space) process could send
a signal to the kernel thread to say "stop that", take over the reading of
unexpended messages and use getmsg() type mechanisms to push messages into
the dmesg buffer. It might be nice if the kernel thread could be reawoken
should the user-space process die, just in case (using SIGCHLD?)
Someone else mentioned they didn't like seeing loads of messages emitted. I
do like it, as it means I can be sure that the OS has booted ok. However,
how about enforcing the log level stuff more, so that a printk without a
KERN_ log-level was ignored, and enabling a kernel-command line parameter
that set the default log level of console messages. So if you did "vmlinux
loglevel=crit" then you only get critical notices?
If we deprecated printk in favour of macros, e.g.:
#define printk_info(x, ...) printk(KERN_INFO ## x, ...)
then it would be (fairly) easy to drop all the "info" level printk's from
the kernel build, shouls the builder wish.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/