On Mon, 2014-01-27 at 14:09 -0800, Linus Torvalds wrote:
> On Mon, Jan 27, 2014 at 11:48 AM, Luck, Tony <tony.luck@xxxxxxxxx> wrote:
> >> 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.
>
> Ok, I think that's a bug. Only an explicit KERN_CONT prefix should
> cause a line continuation.
I don't think it's a bug.
That's never been the case and isn't the case today.
In the past, if the printk buffer string prefix was
"<c>", the emitted string pointer was advanced by 3
and whatever else was emitted.
A dev_<level> though is always effectively newline
terminated even if it doesn't have end in an explicit
'\n'. pr_cont uses after a dev_<level> are always
started on a new line.
That's sometimes unfortunate, but that is a fallout of
Kay's desire to have dev_<level> output always be a
complete message.
There was a patch proposed recently to fix some of the
scsi dev_<level> output followed by KERN_CONT that
previously would have been emitted on a single line
that is now on multiple lines.
https://lkml.org/lkml/2014/1/15/926
> The new msg code seems to be terminally confused about this, and for
> example, seems to completely ignore the KERN_CONT flag, and instead
> tests for just LOG_PREFIX (which is set for any prefix, not the
> KERN_CONT 'c' prefix).
btw: today, KERN_CONT is an empty string, not '<c>'.
include/linux/kern_levels.h:#define KERN_CONT ""
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
