linux-kernel - Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

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: <20160922131103.GW2356@ZenIV.linux.org.uk>
Date:   Thu, 22 Sep 2016 14:11:03 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Jean Delvare <jdelvare@...e.de>
Cc:     Joe Perches <joe@...ches.com>, Julia Lawall <julia.lawall@...6.fr>,
        Ilya Dryomov <idryomov@...il.com>,
        Andy Whitcroft <apw@...onical.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jonathan Corbet <corbet@....net>,
        Ceph Development <ceph-devel@...r.kernel.org>,
        Alex Elder <elder@...nel.org>, Sage Weil <sage@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-doc@...r.kernel.org
Subject: Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

On Thu, Sep 22, 2016 at 01:57:58PM +0200, Jean Delvare wrote:
> > 
> > MUST is much stronger language than I would prefer.
> 
> That's what error means, really. When your compiler fails with an
> error, you have no choice but to fix your code. Warnings on the other
> hand may be ignored sometimes.

And they are errors, because of...?

> Sure. But I'm afraid you keep changing topics and I have no idea where
> you are going. We started with "should there be a space before jump
> labels", then out of nowhere we were discussing the wording of the
> output of checkpatch (how is that related?) and now you pull statistics
> out of your hat, like these numbers imply anything.
> 
> checkpatch was called checkPATCH for a reason. It's main intent was to
> prevent NEW (coding-style mostly) errors from creeping into the kernel.
> The fact that old code does now always follow these recommendations is
> unfortunate but that doesn't make checkpatch wrong or bad.
> 
> ERROR means that the new code isn't allowed to do that. Period.

The main intent of checkpatch these days appears to be providing an easy
way of thoughtless inflation of commit counts, everything else be damned.
Make-work, in other words.

The _only_ criterion for adding new checks should be a strong consensus in
the core kernel.  IOW, it should be descriptive, not prescriptive.  "Some
people do it this way, some - that" is not a valid reason for "let's make it
uniform; that way is just better, so from now on it's a new requirement".
Especially when the rationale behind the choice has all the intellectual
rigour of feng shui.  Some of these checks are common-sense, some are
absolutely arbitrary, there are far too many of them and elevating them
to the level of compiler errors like you seem to do is rather dishonest.