linux-kernel - Re: [PATCH v2] checkpatch: Add a warning for log messages that don't end in a new line

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.20.1711270755280.2369@hadrien>
Date:   Mon, 27 Nov 2017 07:57:15 +0100 (CET)
From:   Julia Lawall <julia.lawall@...6.fr>
To:     Logan Gunthorpe <logang@...tatee.com>
cc:     Joe Perches <joe@...ches.com>, linux-kernel@...r.kernel.org,
        kernel-janitors@...r.kernel.org, Andy Whitcroft <apw@...onical.com>
Subject: Re: [PATCH v2] checkpatch: Add a warning for log messages that don't
 end in a new line



On Sun, 26 Nov 2017, Logan Gunthorpe wrote:

>
>
> On 26/11/17 11:42 PM, Julia Lawall wrote:
> > 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.
>
> Yes, in practice the '\n' at the end of every log line is optional based
> on what the code actually does. Nothing bad happens if you omit one. But
> reviewers still point out that they are required. (That's what started
> me on this mess -- because I'd rather know what the correct thing is
> before I commit the code for the first time, and not months after the
> code reached mainline.)
>
> The reviewers have a really good point though: if a significant fraction
> of the log calls have no new line and a majority have them, then making
> any kind of change in this area could break things. Not to mention the
> ugliness of the inconsistencies everywhere. Also, the more cases that
> are "wrong" that get into the kernel the more it confuses people trying
> to learn what the "right" thing is.

The problem is probably mostly for the non-standard functions, where a lot
of function/macro unfolding is often required to see what is really going
on.

julia


>
> Honestly, though, I have no dog in this race. I just thought it would be
> useful.
>
> Logan
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>