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