> The thing is, unless the next printk is a continuation (PR_CONT), the
> newline should be added at that point. And if it isn't, then that's a
> bug. So I'm wondering how this issue got noticed - does it actually
> cause user-visible issues, or was it just code reading?
The next thing that happened was a debug printk() that didn't have
any log level specified.
printk("CMCI on cpu%d\n", smp_processor_id());
and no newline was added.
> Because I'm wondering if we eventually should start thinking of that
> final '\n' as pointless noise... The fact is, printk has different
> semantics from printf, and maybe we should start taking advantage of
> that rather than just slavishly follow tradition?
Once the janitors have eliminated all the places without a KERN_something,
and I train my fingers to put that in even for throwaway debugging lines,
then perhaps that will work. Output will look a bit odd if you are watching
the serial console as the newlines will be delayed. If some user application
spits out something - then you will also see concatenated things (but jumbled
user/kernel output is hard to avoid).
-Tony
��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
