linux-kernel - Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 20 Sep 2016 01:11:59 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Ilya Dryomov <idryomov@...il.com>
Cc:     Jean Delvare <jdelvare@...e.de>, 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,
        Julia Lawall <julia.lawall@...6.fr>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-doc@...r.kernel.org
Subject: Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was
 Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in
 rbd_header_from_disk())

On Mon, Sep 19, 2016 at 01:53:37PM +0200, Ilya Dryomov wrote:
> > I did consider the reason to be good enough to warrant a "change",
> > actually. Or more exactly from "one space is allowed" to "one space is
> > recommended." Which is quite different from changing all the code
> > actively. I can understand how you don't like it, but again, this
> > "inconsistency" has been accepted for almost a decade now, so I find it
> > strange to see so much resistance when someone finally tries to sort it
> > out.
> 
> Yeah, I guess that's where our disagreement lies - the "so that `diff
> -p` does not confuse labels with functions" in the age of git, hg and
> others, all of which can be customized to your heart's content is not
> a good enough reason to go from "allowed" to "advised".

On the top of CodingStyle we have
"This is a short document describing the preferred coding style for the
linux kernel."

Let's make it s/describing/& (as in "descriptive, not prescriptive")/.
The lack of consensus (in the core kernel areas) is _not_ an invitation
to pick a rule out of one's arse/nose/armpit/textbook/whatnot and stick
it as The One True Style, and references to uniformity are worthless
in such case.

In particular, "whitespace before labels" kind of patches anywhere in
VFS will be simply rejected.

IMO what we need is to go through all rules in CodingStyle and if for
some rule there is no overwhelming majority in the core kernel, well,
the list has grown way too large and could use massive trimming.