On Thu, Apr 03, 2014 at 12:43:08PM +0200, Joerg Roedel wrote: > > How about just ignoring writes to /dev/kmsg altogether by default > (unless explicitly enabled in Kconfig or on the kernel cmdline)? Maybe I > am missing something but what are the legitimate use-cases for generally > allowing user-space to write into the kernel-log?
I'll give you one example which where /dev/kmesg is useful --- if you are running automated kernel tests, echoing "running test shared/127" .... several minutes later .... "running test shared/128", is very useful since if the kernel starts spewing warnings, or even oops/panics/livelocks, you know what test was running at the time of the failure. So in general, most of the valid use cases I can see for /dev/kmesg are small amounts of information where understanding the relationship between what is going in userspace can help understand the kernel warnings, errors, or other printk messages. Which is why I think rate limiting, even with a very low threshold, is a perfectly good alternative. If you need to do bulk logging, and the problem is you want to make sure the information doesn't get lost because syslogd/journald hasn't started up yet, or the file system hasn't been remounted read/write yet, there is a simple answer to this, and it doesn't involve spamming the kernel ring buffer (because kernel memory is non-swappable). The answer is logsave(8), which I developed to solve this specific problem. I wanted to make sure distributions could capture the output of fsck, even when checking the read-only root file system. Note that I did not even *consider* spamming the dmesg log with e2fsck output. Instead, I created a userspace logsave process which could buffer the output (which of course was still displayed on the console) until the root file system was writeable (and/or /var was mounted), at which point the contents could be saved to a file in /var/log. So there are so many other ways of solving this problem without trying to abuse the kernel logging facilities (which were never intended to be a general-purpose syslog replacement). I suspect some systemd developer was being lazy.... - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/