[lkml]   [2006]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Get rid of most of the remaining k*alloc() casts.
    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

    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-12-19 20:51    [W:0.022 / U:13.980 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site