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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
