linux-kernel - Re: [Ksummit-2013-discuss] [PATCH] checkpatch: Add comment about updating Documentation/CodingStyle

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]

Date:	Mon, 2 Sep 2013 16:48:24 -0300
From:	Mauro Carvalho Chehab <mchehab@...radead.org>
To:	Joe Perches <joe@...ches.com>
Cc:	Josh Triplett <josh@...htriplett.org>,
	linux-kernel@...r.kernel.org, Andy Whitcroft <apw@...onical.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	ksummit-2013-discuss@...ts.linuxfoundation.org,
	David Howells <dhowells@...hat.com>
Subject: Re: [Ksummit-2013-discuss] [PATCH] checkpatch: Add comment about
 updating Documentation/CodingStyle

Em Mon, 02 Sep 2013 11:59:27 -0700
Joe Perches <joe@...ches.com> escreveu:

> On Mon, 2013-09-02 at 15:39 -0300, Mauro Carvalho Chehab wrote:
> > Em Mon, 2 Sep 2013 11:19:01 -0700
> > Josh Triplett <josh@...htriplett.org> escreveu:
> []
> > > +# This file does not define the kernel coding style; Documentation/CodingStyle
> > > +# does.  If you add a new style test to this file, add the corresponding style
> > > +# rule it enforces to Documentation/CodingStyle.
> 
> > Agreed with that.
> 
> I do not.
> 
> > I would also add another comment there: "in case of
> > conflicts between checkpatch.pl and Documentation/CodingStyle, the latter
> > takes precedence."
> 
> There are many checkpatch rules (like semicolons) that
> are not in CodingStyle.

Well, document them there, please.

> CodingStyle should not become some intensely detailed
> document that specifies the "only one true way" to
> write code.

There will always be things that will be freed to the programmer to
use, but CodingStyle should reflect what is the coding style we're
adopting at the Kernel, or putting it on another way: what things
will make the patch to be rejected because of its style.

> I also think checkpatch should not be used by robots
> to determine that patches are bad or unacceptable.
> 
> checkpatch is just a dumb little tool that has some
> utility but as Dan Carpenter once said, "it's less
> sentient than a squirrel".
> 
> People should always use their own taste before
> relying on dumb tools.

That's easier said than done. There are lots of stupid changes that are
done by developers (like enforcing 80 cols whitespace breaks) just
because of the checkpatch warnings. That happens before those patches 
got sent to the ML's, as most people know that maintainers will curse 
them if the coding style is crap[1].

[1] BTW, most of the time that checkpatch complains, the code is
really crap.

In any case, Documentation/CodingStyle is the reference document that
maintainers and coders should use to know that a code is following the
style (and not checkpatch). So, it requires updates when new
CodingStyle enforcements are created.

In the specific example pointed by David, if "extern", will start
to become a bad word that should be avoided, that should be documented
there at CodingStyle, and checkpatch should just be the dumb monkey
that will check that.

Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/