linux-kernel - Re: Merging of completely unreviewed drivers

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]

Message-ID: <20080222194459.GA21250@kroah.com>
Date:	Fri, 22 Feb 2008 11:44:59 -0800
From:	Greg KH <greg@...ah.com>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Adrian Bunk <bunk@...nel.org>,
	Roland Dreier <rdreier@...co.com>,
	Glenn Streiff <gstreiff@...Effect.com>,
	Faisal Latif <flatif@...Effect.com>,
	linux-kernel@...r.kernel.org, general@...ts.openfabrics.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: Merging of completely unreviewed drivers

On Fri, Feb 22, 2008 at 02:20:12PM -0500, Jeff Garzik wrote:
> Ingo Molnar wrote:
>>  2) you might know that Deja-Vu moment when you look at a new patch that   
>>   has been submitted to lkml and you have a strange, weird "feeling"     
>> that there's something wrong about the patch.
>>     It's totally subconscious, and you take a closer look and a few
>>     seconds later you find a real bug in the code.
>>     That "feeling" i believe comes from a fundamental property of how     
>> human vision is connected to the human brain: pattern matching.     Really 
>> good programmers have built a "library" of patterns of "good"     and 
>> "bad" looking coding practices.
>>     If a patch or if a file has a clean _style_, bugs and deeper     
>> structural problems often stand out like a sore thumb. But if the 
> [...]
>
>>     The best programmers are the ones who have a good eye for details -    
>>  and that subconsciously extends to "style details" too. I've yet to
>>     see a _single_ example of a good, experienced kernel programmer who    
>>  writes code that looks absolutely careless and sloppy, but which is     
>> top-notch otherwise. (Newbies will make style mistakes a lot more     
>> often - and for them checkpatch is a nice and easy experience at     
>> reading other people's code and trying to learn the style of the     
>> kernel.)
> [...]
>
>>  4) there's a psychological effect as well: clean _looking_ code is     
>> more attractive to coders to improve upon. Once the code _looks_     clean 
>> (mechanically), the people with the real structural cleanups     are not 
>> far away either. Code that just looks nice is simply more of     a 
>> pleasure to work with and to improve, so there's a strong     
>> psychological relationship between the "small, seemingly unimportant     
>> details" cleanups and the real, structural cleanups.
>
> The above deserved to be quoted...  just because I agree with all of it so 
> strongly :)
>
> Bugs really do "hide" in ugly code, in part because my brain has been 
> optimized to review clean code.
>
> Like everything else in life, one must strike a balance between picking 
> style nits with someone's patch, and making honest criticisms of a patch 
> because said patch is too "unclean" to be reviewed by anyone.

I totally agree with all of this.  checkpatch.pl is a useful tool to
use, and is quite handy for helping the kernel code for all of the above
reasons.

</aol>

thanks,

greg k-h
--
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/