Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932925AbWLSUIB (ORCPT ); Tue, 19 Dec 2006 15:08:01 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932930AbWLSUIB (ORCPT ); Tue, 19 Dec 2006 15:08:01 -0500 Received: from mx1.cs.washington.edu ([128.208.5.52]:57198 "EHLO mx1.cs.washington.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932925AbWLSUIA (ORCPT ); Tue, 19 Dec 2006 15:08:00 -0500 Date: Tue, 19 Dec 2006 12:07:58 -0800 (PST) From: David Rientjes To: "Robert P. J. Day" cc: Linux kernel mailing list Subject: Re: [PATCH] Get rid of most of the remaining k*alloc() casts. In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2111 Lines: 46 On Tue, 19 Dec 2006, Robert P. J. Day wrote: > that sounds reasonable but, as i've mentioned before, many of the > sizable cleanups i've submitted are produced by a simple script, which > is written to process *one* kind of cleanup. if i tried to fix > everything else in the same area at the same time, *that* would > involve far more manual labour, not to mention that the patch would be > less well-defined, and the probability of a fatal typo would actually > increase. > If these cleanups are being generated by a simple script, I would suggest making sure that script works before submitting patches which break the kernel. On the other hand, if that script is only being used to point you in the direction of a possible cleanup, then it takes very little effort to move an asterisk as one person already suggested, get rid of whitespace, or make a kzalloc conversion. > it's also possible that the stuff that isn't getting fixed in *this* > cleanup will be done in a future submission. like i said, it's a > tradeoff. i'm certainly open to suggestions but there's not much > chance that, when i attack one issue, i'm then going to manually > inspect every line that was changed to see what *else* could be done > at the same time. > When you submit patches to the kernel, I would recommend inspecting each line before submitting it. > life's just too short for that. > I'm quite positive life's too short for the people who may apply your patch to their tree to deal with trivial typos that cause their compile to break or, worse, a problem that may not be noticed at runtime but silently manifests itself later. Having four incremental patches for this: remove casts, move asterisks, eliminate whitespace, and kzalloc conversions is not the solution. Roll it into one patch, call it a cleanup, inspect it, then _test_ it. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/