Re: [GIT PULL] trivial for 4.9

[Linus Torvalds]

On Fri, Oct 7, 2016 at 4:09 PM, Tony Luck <tony.luck@xxxxxxxxx> wrote:
> On Fri, Oct 7, 2016 at 4:01 PM, Tony Luck <tony.luck@xxxxxxxxx> wrote:
>> What if there isn't a "next printk" call for hours, or days?
>>
>> That poor little message without a "\n" will sit in the kernel buffers,
>> and the user who might want to see the message can't, until some
>> unrelated thing happens to print something.
>
> Retracted ...  I'm sure that at some point in the past it happened
> like that ...  but I just retested on 4.8 and the first message (with
> no "\n") showed up on the serial port just fine without some other
> message to push it out.  When the next message came along, a "\n" was
> auto-inserted.

Yeah, that immediate printout has actually always worked fine - the
newline was never really a buffering thing.

The buffering actually came fairly late, with the "newfangled"
record-oriented logging facility (4+ years old by now).

Our kernel message log was historically just a plain buffer, and not
record-oriented at all. You'd just read and write it as a stream. In
that historical context, it made tons of sense to just write something
without a newline, and then continue writing on the same line: that's
how <stderr> always works.

But back in 2012, Kay Sievers wanted to make it record-based, because
reasons. That *really* doesn't play well with the whole "oh, you might
not get the whole thing in one go" model, and things were broken a few
times. It also made our printk implementation a lot more complex. But
there was some argument for a full-featured syslog facility.  Line
continuations suddenly weren't very natural any more, because now a
continuation printk was very much a "broken record".

Anyway, the complexity has had upsides too, and the "let's not require
'\n' at the end" actually came in through that (in fact, I think the
record-based internal format removes the newlines at the end of
characters). And there are some real advantages, both with timestamps
and with having per-record log levels. So it's definitely not all bad,
but there's a fair amount of complexity in there. The old model was
rather broken in other ways, though, so on the whole I think we're
doing fairly ok.

But yes, the line continuation that *used* to be very natural (but
always had problems with concurrent output from multiple contexts)
definitely makes for extra complexity in the record-based model. But
exactly *because* the record-based thing needs to be more careful
about those newlines, it actually ended up being why the explicit "\n"
thing at the end of a printk shouldn't really matter any more.

And not having it does make for nicer printk strings. "Just the facts".

             Linus