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

["Robert P. J. Day" <rpjday@mindspring.com>]

On Tue, 19 Dec 2006, David Rientjes wrote:

> On Tue, 19 Dec 2006, Robert P. J. Day wrote:
>
> > diff --git a/include/asm-um/thread_info.h b/include/asm-um/thread_info.h
> > index 261e2f4..e43c2dd 100644
> > --- a/include/asm-um/thread_info.h
> > +++ b/include/asm-um/thread_info.h
> > @@ -51,8 +51,7 @@ static inline struct thread_info *current_thread_info(void)
> >  }
> >
> >  /* thread information allocation */
> > -#define alloc_thread_info(tsk) \
> > -	((struct thread_info *) kmalloc(THREAD_SIZE, GFP_KERNEL))
> > +#define alloc_thread_info(tsk) kmalloc(THREAD_SIZE, GFP_KERNEL))
> >  #define free_thread_info(ti) kfree(ti)
> >
> >  #endif
>
> This patch breaks all of usermode from the change above.

whoops, you're right, i didn't notice that.  duh.  i can resubmit that
patch with that part whacked out, or someone higher up the food chain
can do that.  either way works for me.  sorry about that.

> There's also no reason to avoid other cleanups in the area you're
> changing (and testing) such as moving the asterisk for pointers to
> the variable name, deleting extraneous whitespace, or changing the
> several instances in this patch where kzalloc conversion is
> appropriate.  If it's not done now, it will either be forgotten or
> another patch on the same elaborate scale as this one will need to
> fix it incrementally.  Given the high chance of typos such as the
> one above in broad patches like this, all the changes should be
> rolled together into one patch that is at least inspected before
> submission by the author.

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.

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.

life's just too short for that.

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