Re: [PATCH] Get rid of most of the remaining k*alloc() casts.

[David Rientjes]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/