linux-kernel - Re: [RFC PATCH 5/5 v2] Convert tasklets to work queues

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: <alpine.LFD.0.98.0706231209130.3593@woody.linux-foundation.org>
Date:	Sat, 23 Jun 2007 12:18:51 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Randy Dunlap <rdunlap@...otime.net>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, tglx@...utronix.de,
	hch@...radead.org, johnstul@...ibm.com, oleg@...sign.ru,
	paulmck@...ux.vnet.ibm.com, dipankar@...ibm.com,
	davem@...emloft.net, kuznet@....inr.ac.ru
Subject: Re: [RFC PATCH 5/5 v2] Convert tasklets to work queues

On Sat, 23 Jun 2007, Randy Dunlap wrote:
> > 
> > Quite frankly, I personally am considering removing "checkpatch.pl". That 
> > thing is just a nazi dream. That hard-coded 80-character limit etc is just 
> > bad taste.
> 
> Who wrote that part of CodingStyle?

I don't think that the notion of "80 characters per line" is *wrong* per 
se.

So don't take this the wrong way - I think the goal really _should_ be 
that a function fits on a vt100 terminal window (*both* ways: less than 24
lines of code, and less than 80 characters wide).

So I think the notion of trying to keep lines below 80 characters is 
admirable. That part isn't the problem.

The problem is when "coding style guidelines" become "hard inviolate 
rules".

Yes, code should be less than 80 characters wide. 

But hey, sometimes it's just more readable to have one line that is 
slightly longer than it should be, than to split something that is awkward 
to split. 

The thing that scripts (and computers) have a really hard time with is 
"judgement". 

So I don't disagree with any of the checkpatch.pl things individually, but 
I do disagree with the notion that we should enforce strict rules, when 
all the guidelines are really just guidelines.

For example, the coding style also says that you should avoid indentation 
that is more than tree deep. It's _true_, but does that mean that we 
should make deeply indented code *illegal*? Obviously not. It's a "please 
try to split your functions up" kind of thing.  Not a hard rule.

The only reason I picked the 80-character thing in particular is that 
I've seen a fair number of patches that don't do anything *but* change 
that, and quite often I think it makes the code look worse if it's not 
done judiciously..

There are other things we really *could* be strict against. For example, 
the "space followed by tab" thing really is somethign where a strict rule 
(at least for C files) probably really *is* a good idea, because there 
really is never a really good reason for it. Add the fact that the problem 
is "invisible" in most editors, and having a script that checks for it 
makes even more sense.

So I'm happy with checkpatch.pl as a *guide*, but I'm not happy if it 
means that people start taking it as a *requirement*.

(And then I'm doubly unhappy when there are issues like code movement and 
file renames etc, where there are other reasons why we actually want to 
keep the code as unmodified as possible).

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