mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org, mingo@elte.hu, tglx@linutronix.de,
	hch@infradead.org, johnstul@us.ibm.com, oleg@tv-sign.ru,
	paulmck@linux.vnet.ibm.com, dipankar@in.ibm.com,
	davem@davemloft.net, kuznet@ms2.inr.ac.ru
Subject: Re: [RFC PATCH 5/5 v2] Convert tasklets to work queues
Date: Sat, 23 Jun 2007 11:19:18 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.0.98.0706231113200.3593@woody.linux-foundation.org> (raw)
In-Reply-To: <20070623095359.4667514e.akpm@linux-foundation.org>



On Sat, 23 Jun 2007, Andrew Morton wrote:
> 
> Anyway.  Please fix the many correct warnings which checkpatch.pl
> generates

Actually, please don't.

Especially for code movement, *just* do the movement. Screw any 
checkpatch.pl crap - the code is better off not changing, because that way 
a big patch can not only be proven to not change anything at all, but 
software archeology tools can trivially find the true history of the code 
over code movement.

For example, "git blame -C" already finds copies and can annotate the 
history of a line of code past a pure code movement. But if you move *and* 
change things at the same time, it gets a lot harder to show where the 
code came from and that the movement itself caused no regressions.

So do cleanups _separately_ from movement.

(Yeah, yeah, "git blame -C -w" will generally work across whitespace 
changes too, but only whitespace _within_ a line. If you do things like 
split long lines etc, you immediately have a lot harder time to follow 
these thigns. Not impossible, but the point is that you're not *fixing* 
anything, you're just making things *worse* by doing changes and code 
movement at the same time).

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. 

Dammit, code cleanliness is not about "automated and mindless slavish 
following of rules". A process that is too inflexible is a *bad* process. 
I'd much rather have a few 80+ character lines than stupid and unreadable 
line wrapping just because the line hit 87 characters in length.

I don't have 25 lines on a screen either. 

		Linus

  parent reply	other threads:[~2007-06-23 18:26 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-22 18:20 [RFC PATCH 0/5 v2] Convert all tasklets to workqueues V2 Steven Rostedt
2007-06-22 18:20 ` [RFC PATCH 1/5 v2] Convert the RCU tasklet into a softirq Steven Rostedt
2007-06-22 22:53   ` Paul E. McKenney
2007-06-22 18:20 ` [RFC PATCH 2/5 v2] Split out tasklets from softirq.c Steven Rostedt
2007-06-22 18:20 ` [RFC PATCH 3/5 v2] Add a tasklet is-scheduled API Steven Rostedt
2007-06-22 18:20 ` [RFC PATCH 4/5 v2] Make DRM use the tasklet is-sched API Steven Rostedt
2007-06-22 18:20 ` [RFC PATCH 5/5 v2] Convert tasklets to work queues Steven Rostedt
2007-06-23 16:53   ` Andrew Morton
2007-06-23 18:00     ` Steven Rostedt
2007-06-23 18:19     ` Linus Torvalds [this message]
2007-06-23 18:52       ` Randy Dunlap
2007-06-23 18:58         ` Andrew Morton
2007-06-23 19:18         ` Linus Torvalds
2007-07-08  0:49           ` Coding style on function signatures (was: Convert tasklets to work queues ) Jim Cromie
2007-07-08  4:37             ` Randy Dunlap
2007-07-08  6:02               ` Oleg Verych
2007-07-08 10:12             ` Jan Engelhardt
2007-06-23 19:27       ` [RFC PATCH 5/5 v2] Convert tasklets to work queues Steven Rostedt
2007-06-23 19:39         ` Andrew Morton
2007-06-23 22:09         ` Linus Torvalds
2007-06-28  6:57       ` Jeff Garzik
2007-06-23 17:17   ` Oleg Nesterov
2007-06-23 21:15 ` [RFC PATCH 0/5 v2] Convert all tasklets to workqueues V2 Ed Tomlinson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.0.98.0706231113200.3593@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=dipankar@in.ibm.com \
    --cc=hch@infradead.org \
    --cc=johnstul@us.ibm.com \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@tv-sign.ru \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®