linux-kernel - Re: Checkpatch Feature Idea: Search directory for files with errors and warnings with -d argument

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 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:	Wed, 16 Jul 2014 06:08:36 -0700
From:	Joe Perches <joe@...ches.com>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Nick Krause <xerofoify@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	josh@...htriplett.org, robh@...nel.org, florian.vaussard@...l.ch,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Checkpatch Feature Idea: Search directory for files with errors
 and warnings with -d argument

On Wed, 2014-07-16 at 04:05 -0400, Theodore Ts'o wrote:
> On Tue, Jul 15, 2014 at 09:39:52PM -0700, Joe Perches wrote:
[]
> > Consistency is a nicety not really a need.
> > 
> > Bugs need fixing.  Defects need eliminating.
> > Enhancements are appreciated.  Inconsistent
> > code style is a minor annoyance.
> 
> Note that patches that clean up code style can in fact be actively
> harmful, because it interferes with other developers who are sending
> patches that fix real bugs and and add new features (because the
> cleanups cause patch conflicts).
[]
> Cleanups as a part of normal code development is fine.
[]
> fixing
> every single nit that checkpatch whines about in a while adds no
> value, and in fact, can add negative value.

I think the negatives are a bit overstated.

As long as style only patches are scheduled, coordinated,
and done with a much lower priority than other real work,
there is some marginal positive value in code style
consistency.

Humans more easily read code of multiple subsystems.
Defects in existing code are sometimes uncovered.
More consistent API use is encouraged.

There are real tradeoffs to be considered in developer
time vs value though.

Even whitespace changes need review and acceptance from
upstream maintainers to make sure defects and new security
issues aren't introduced.

Upstream maintainer time is not cheap and frequently the
upstream maintainer is not cheerful either.

> (Also note that there are some local coding practices where there are
> very good reasons why the checkpatch whines need to be completely
> ignored.  For example, you checkpatch doesn't deal well with the file
> format used in include/tracing/events/*.h.  You need to know when the
> right thing to do is to say, "Go home, checkpatch, you're drunk.")

checkpatch can be a bit of an OCD drunk.  Codetenders
have the responsibility to cut it off when its spent
too long at the file bar.

Of course it's true that checkpatch needs to have its
own bugs fixed and defects eliminated too.

--
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/