Tue, Apr 21, 2009 at 10:37:41AM -0700, Linus Torvalds wrote: > > > On Tue, 21 Apr 2009, David VomLehn wrote: > > > > What in the world are users going to do when they see a message about > > output being lost? There is no way to recover the data and no way to > > prevent it in the future. I don't think this is a good approach. > > Sure there is. The console messages are saved too, so doing 'dmesg' will > get you all the data that was generated before the console went on-line. > > We _already_ lose data in that sense (although we could replay it for the > first console connected - maybe we even do, I'm too lazy to check). There are two different things coming out on the console, kernel log buffer messages and userspace output to /dev/console. Kernel log buffer output is replayed for each console as it connects. There might be quite a bit of it, but it is pretty much the same from boot to boot, so the guy working on the kernel, me, can tune the size of log_buf pretty easily. This is not the problem. The problem is the userspace output to /dev/console. I work in the embedded space and my box does not simply throw up a few windows and wait placidly for the user to do something. Instead, it immediately starts running a whole bunch of software with a whole bunch of startup messages. In short order, I am running over 300 threads. I have no control over how much output comes out, I have no idea how much kernel memory to allocate for this, and I'm quote sure it's enough that I wouldn't want to waste that much space even if I did. No matter what, this looks like we'd need a new tunable for the size. And then, what happens if I *never* get a console, because one isn't plugged in? This happens a lot in the embedded world. How long am I supposed to keep around this big chunk of buffered data? Sounds like I need *another* tunable. Yuck. > Linus -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html