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
| ||
|
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/
Powered by blists - more mailing lists