RE: kernel support for non-english user messages

[Ruth Ivimey-Cook]

At 22:20 10/04/2003, Perez-Gonzalez, Inaky wrote:
> > >Ruth Ivimey-Cook wrote:
> > >> results in the following in the kernel buffer:
> > >> "%s: name %p is %d\n", "stringval", 0x4790243, 44
> > > Debugging a non-klogd enabled kernel would be a pain
> >  Why?  Shouldn't it be easy to fix dmesg so it unmangles the output?
>s/non-klogd enabled/dmesg/
>Same thing - what I mean is that if you don't have some automatic
>means to recompose the messages, reading the direct output of
>the console (as sometimes you have to), becomes a mess.

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.

HTH,

Ruth