From: Joe Perches <joe@perches.com>
To: Julia Lawall <julia.lawall@lip6.fr>
Cc: Logan Gunthorpe <logang@deltatee.com>,
linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org,
Andy Whitcroft <apw@canonical.com>
Subject: Re: [PATCH v2] checkpatch: Add a warning for log messages that don't end in a new line
Date: Mon, 27 Nov 2017 09:03:21 +0000 [thread overview]
Message-ID: <1511773401.32426.21.camel@perches.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1711270741190.2369@hadrien>
On Mon, 2017-11-27 at 07:42 +0100, Julia Lawall wrote:
> On Mon, 27 Nov 2017, Julia Lawall wrote:
> > On Sun, 26 Nov 2017, Joe Perches wrote:
> > > On Sun, 2017-11-26 at 19:17 +0100, Julia Lawall wrote:
> > > > I just assume that a printk that has no KERN_ is adding a
> > > > newline, which is my understanding of Joe's comment.
> > >
> > > More precisely:
> > >
> > > Any printk without an initial KERN_CONT prepends a newline
> > > if the last printk content char emitted that is not part
> > > of a printk timestamp/header was not a newline.
> >
> > Ah, I misunderstood. I thought it was any printk that has no KERN
> > indicator at all. That I can fix.
>
> Although I guess that in that case the whole exercise is pointless?
> Because every print will at runtime be followed by another print, which
> will add either the newline or a continuation.
Kinda yes and no.
A printk without a newline termination is not emitted
as output until the next printk call.
This can cause issues on quiescent systems as the printk
is not emitted for potentially a very long time.
Also, any thread interleaving can still cause misformatted
output.
and:
All the historical printks without KERN_CONT worked well
until the commit that broke them by requiring KERN_CONT.
But now these consecutive calls to printk which used to be
emitted on on a single line are printed on multiple lines.
The title of the commit is wrong as KERN_CONT was not
necessary before this change.
---
commit 4bcc595ccd80decb4245096e3d1258989c50ed41
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sat Oct 8 20:32:40 2016 -0700
printk: reinstate KERN_CONT for printing continuation lines
---
So IMO it's _somewhat_ useful to try to update the printks
without either
KERN_CONT or with a KERN_<LEVEL> but
without a newline.
As the above commit is about a year old, most of the cases
in the code that are actually likely have been fixed by now.
WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: Julia Lawall <julia.lawall@lip6.fr>
Cc: Logan Gunthorpe <logang@deltatee.com>,
linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org,
Andy Whitcroft <apw@canonical.com>
Subject: Re: [PATCH v2] checkpatch: Add a warning for log messages that don't end in a new line
Date: Mon, 27 Nov 2017 01:03:21 -0800 [thread overview]
Message-ID: <1511773401.32426.21.camel@perches.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1711270741190.2369@hadrien>
On Mon, 2017-11-27 at 07:42 +0100, Julia Lawall wrote:
> On Mon, 27 Nov 2017, Julia Lawall wrote:
> > On Sun, 26 Nov 2017, Joe Perches wrote:
> > > On Sun, 2017-11-26 at 19:17 +0100, Julia Lawall wrote:
> > > > I just assume that a printk that has no KERN_ is adding a
> > > > newline, which is my understanding of Joe's comment.
> > >
> > > More precisely:
> > >
> > > Any printk without an initial KERN_CONT prepends a newline
> > > if the last printk content char emitted that is not part
> > > of a printk timestamp/header was not a newline.
> >
> > Ah, I misunderstood. I thought it was any printk that has no KERN
> > indicator at all. That I can fix.
>
> Although I guess that in that case the whole exercise is pointless?
> Because every print will at runtime be followed by another print, which
> will add either the newline or a continuation.
Kinda yes and no.
A printk without a newline termination is not emitted
as output until the next printk call.
This can cause issues on quiescent systems as the printk
is not emitted for potentially a very long time.
Also, any thread interleaving can still cause misformatted
output.
and:
All the historical printks without KERN_CONT worked well
until the commit that broke them by requiring KERN_CONT.
But now these consecutive calls to printk which used to be
emitted on on a single line are printed on multiple lines.
The title of the commit is wrong as KERN_CONT was not
necessary before this change.
---
commit 4bcc595ccd80decb4245096e3d1258989c50ed41
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sat Oct 8 20:32:40 2016 -0700
printk: reinstate KERN_CONT for printing continuation lines
---
So IMO it's _somewhat_ useful to try to update the printks
without either
KERN_CONT or with a KERN_<LEVEL> but
without a newline.
As the above commit is about a year old, most of the cases
in the code that are actually likely have been fixed by now.
next prev parent reply other threads:[~2017-11-27 9:03 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-26 5:40 [PATCH v2] checkpatch: Add a warning for log messages that don't end in a new line Logan Gunthorpe
2017-11-26 5:40 ` Logan Gunthorpe
2017-11-26 5:51 ` Julia Lawall
2017-11-26 5:51 ` Julia Lawall
2017-11-26 6:01 ` Joe Perches
2017-11-26 6:01 ` Joe Perches
2017-11-26 17:38 ` Logan Gunthorpe
2017-11-26 17:38 ` Logan Gunthorpe
2017-11-26 22:29 ` Joe Perches
2017-11-26 22:29 ` Joe Perches
[not found] ` <alpine.DEB.2.20.1711262334370.2111@hadrien>
2017-11-27 1:12 ` Joe Perches
2017-11-27 1:12 ` Joe Perches
2017-11-27 6:08 ` Julia Lawall
2017-11-27 6:08 ` Julia Lawall
2017-11-27 9:25 ` Joe Perches
2017-11-27 9:25 ` Joe Perches
2017-11-27 9:32 ` Julia Lawall
2017-11-27 9:32 ` Julia Lawall
2017-11-27 9:42 ` Joe Perches
2017-11-27 9:42 ` Joe Perches
2017-11-27 17:07 ` Logan Gunthorpe
2017-11-27 17:07 ` Logan Gunthorpe
2017-11-27 17:26 ` Joe Perches
2017-11-27 17:26 ` Joe Perches
2017-11-27 17:33 ` Logan Gunthorpe
2017-11-27 17:33 ` Logan Gunthorpe
2017-11-27 17:41 ` Joe Perches
2017-11-27 17:41 ` Joe Perches
2017-11-27 17:42 ` Logan Gunthorpe
2017-11-27 17:42 ` Logan Gunthorpe
2017-11-27 4:00 ` Logan Gunthorpe
2017-11-27 4:00 ` Logan Gunthorpe
2017-11-27 6:11 ` Julia Lawall
2017-11-27 6:11 ` Julia Lawall
2017-11-27 6:27 ` Logan Gunthorpe
2017-11-27 6:27 ` Logan Gunthorpe
2017-11-27 6:34 ` Julia Lawall
2017-11-27 6:34 ` Julia Lawall
2017-11-27 6:40 ` Logan Gunthorpe
2017-11-27 6:40 ` Logan Gunthorpe
2017-11-27 8:28 ` Joe Perches
2017-11-27 8:28 ` Joe Perches
2017-11-27 8:52 ` Julia Lawall
2017-11-27 8:52 ` Julia Lawall
2017-11-27 9:06 ` Joe Perches
2017-11-27 9:06 ` Joe Perches
2017-11-27 16:40 ` Logan Gunthorpe
2017-11-27 16:40 ` Logan Gunthorpe
2017-11-27 17:20 ` Logan Gunthorpe
2017-11-27 17:20 ` Logan Gunthorpe
2017-11-27 17:28 ` Joe Perches
2017-11-27 17:28 ` Joe Perches
2017-11-27 17:35 ` Logan Gunthorpe
2017-11-27 17:35 ` Logan Gunthorpe
2017-11-27 17:42 ` Joe Perches
2017-11-27 17:42 ` Joe Perches
2017-11-27 17:44 ` Logan Gunthorpe
2017-11-27 17:44 ` Logan Gunthorpe
2017-11-27 18:57 ` Joe Perches
2017-11-27 18:57 ` Joe Perches
2017-11-27 19:58 ` Logan Gunthorpe
2017-11-27 19:58 ` Logan Gunthorpe
2017-11-27 20:49 ` Julia Lawall
2017-11-27 20:49 ` Julia Lawall
2017-11-27 22:56 ` Logan Gunthorpe
2017-11-27 22:56 ` Logan Gunthorpe
2017-11-28 0:15 ` Joe Perches
2017-11-28 0:15 ` Joe Perches
2017-11-26 16:55 ` Logan Gunthorpe
2017-11-26 16:55 ` Logan Gunthorpe
2017-11-26 17:09 ` Julia Lawall
2017-11-26 17:09 ` Julia Lawall
2017-11-26 17:47 ` Logan Gunthorpe
2017-11-26 17:47 ` Logan Gunthorpe
2017-11-26 18:17 ` Julia Lawall
2017-11-26 18:17 ` Julia Lawall
2017-11-26 18:33 ` Logan Gunthorpe
2017-11-26 18:33 ` Logan Gunthorpe
2017-11-27 1:35 ` Joe Perches
2017-11-27 1:35 ` Joe Perches
2017-11-27 6:40 ` Julia Lawall
2017-11-27 6:40 ` Julia Lawall
2017-11-27 6:42 ` Julia Lawall
2017-11-27 6:42 ` Julia Lawall
2017-11-27 6:53 ` Logan Gunthorpe
2017-11-27 6:53 ` Logan Gunthorpe
2017-11-27 6:57 ` Julia Lawall
2017-11-27 6:57 ` Julia Lawall
2017-11-27 9:03 ` Joe Perches [this message]
2017-11-27 9:03 ` Joe Perches
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1511773401.32426.21.camel@perches.com \
--to=joe@perches.com \
--cc=apw@canonical.com \
--cc=julia.lawall@lip6.fr \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=logang@deltatee.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.