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 <>
To:	Theodore Ts'o <>
Cc:	Nick Krause <>,
	Andrew Morton <>,,,,
	"" <>
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

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
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists