Messages in this thread | | | Date | Fri, 11 Apr 2003 21:55:14 +0100 | From | Ruth Ivimey-Cook <> | Subject | RE: kernel support for non-english user messages |
| |
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
- 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/
| |