On Sat 2018-11-10 11:42:03, Tetsuo Handa wrote: > On 2018/11/10 0:43, Petr Mladek wrote: > >> + * Line buffered printk() tries to assign a buffer when printk() from a new > >> + * context identifier comes in. And it automatically releases that buffer when > >> + * one of three conditions listed below became true. > >> + * > >> + * (1) printk() from that context identifier emitted '\n' as the last > >> + * character of output. > >> + * (2) printk() from that context identifier tried to print a too long line > >> + * which cannot be stored into a buffer. > >> + * (3) printk() from a new context identifier noticed that some context > >> + * identifier is reserving a buffer for more than 10 seconds without > >> + * emitting '\n'. > >> + * > >> + * Since (3) is based on a heuristic that somebody forgot to emit '\n' as the > >> + * last character of output(), pr_cont()/KERN_CONT users are expected to emit > >> + * '\n' within 10 seconds even if they reserved a buffer. > > > > This is my main concern about this approach. It is so easy to omit > > the final '\n'. > > If it is so easy to forget the final '\n', there will be a lot of implicit > pr_cont() users (because pr_cont() assumes that previous printk() omitted the > final '\n'), and "I am going to investigate much more pr_cont() users." will > be insufficient for getting meaningful conclusion. > > Checking "lack of the the final '\n'" means that we need to check > "all printk() users who are not emitting the final '\n'" and evaluate > "whether there is a possibility that subsequent printk() will not be > called from that context due to e.g. conditional branches". That is an > impossible task for anybody, for there might be out-of-tree code doing it. > > > > They are currently delayed until another printk(). Even this is bad. > > Unfortunately we could not setup timer from printk() because it > > would add more locks into the game. > > We could use interval timer for flushing incomplete line. I am more and more wondering if the buffered printk is worth the effort. The more buffers we use the more we risk that nobody would see some important message. Even a part of the line might be crucial in some situations. Steven told me on Plumbers conference that even few initial characters saved him a day few times. > But updating printk() users to always end with '\n' will be preferable. This sounds like a whack a mole game. If I get it correctly, you write that it is "an impossible task for anybody" just few lines above. Best Regards, Petr
