linux-kernel - Re: [PATCH x86] [12/16] Optimize lock prefix switching to run less frequently

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:	Sat, 5 Jan 2008 15:37:28 +0100
From:	Andi Kleen <ak@...e.de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Andi Kleen <ak@...e.de>, Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH x86] [12/16] Optimize lock prefix switching to run less
	frequently

> Sloppy and inconsistent code also leaves a lasting negative impression 
> on newbie developers. I've heard quite a few opinions about Linux's code 
> base being a lot less consistent (and hence harder to understand) than 

Do you think they did refer to code style (as in indentation etc.) here? 
When I was talking to such people my impression was that their complaints
usually came from other issues.

e.g. I know from talking to a few people that they consider the BSD
kernels cleaner just because they have a very consistent printk
style for driver probing so it looks cleaner at booting. Sounds silly
(although I can sympathize a little bit) but true.

Besides the kernel indentation is not that inconsistent anyways.

> Frankly, if you dont understand the necessity of clean code, and the 
> negative effect that a large number of small uncleanlinesses can have on 
> a large system then you wont be getting the big picture either.
> 
> checkpatch.pl is not perfect (and it cannot be), and we dont use it as a 
> rigid criterium (and dont want to), but it's quite conservative (its 
> false positive rate for code that i maintain is below 1% - which is 

Rate is certainly higher here.

> sloppy patches. It gives us a way to improve the kernel's code quality 
> gradually. We change about 10% of the kernel codebase in every kernel 
> release, that is about 30% of the kernel every year. With checkpatch.pl 
> we'll have a very clean kernel in just a few years.

That's the problem I have with your position. You equate quality
with coding style or checkpatch.pl output. I think it's only a small
part of it.

If we follow your description above to the logical conclusion then we could 
get the perfect kernel(tm) very quickly just by running everything 
through Lindent or recruit a few hundred people who run all files 
through checkpatch.pl and fix all warnings and then we end up with the 
perfect kernel with "improved code quality" 

Great idea! And is it ok for me to refer to that plan as "the Ingo Molnar
plan" (TIMP) in the future? I'm sure a short term for it will come handy 
in future discussions ;-)

-Andi

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