lkml.org 
[lkml]   [2003]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.5.67-mm2
    Hi Andrew,
    hi lists readers,

    On Sat, Apr 12, 2003 at 06:08:52PM -0700, Andrew Morton wrote:
    > +gfp_repeat.patch
    >
    > Implement __GFP_REPEAT: so we can consolidate lots of alloc-with-retry code.

    What about reworking the semantics of kmalloc()?

    Many users of kmalloc get the flags and size reversed (major
    source of hard to find bugs), so wouldn't it be simpler to have:

    __kmalloc() /* The old kmalloc()*/

    kmalloc() /* kmalloc(, GFP_KERNEL) */
    kmalloc_user() /* kmalloc(, GFP_USER) */
    kmalloc_dma() /* kmalloc(, GFP_KERNEL | GFP_DMA) */
    kmalloc_dma_repeat() /* kmalloc(, GFP_KERNEL | GFP_DMA | __GFP_REPEAT) */
    kmalloc_repeat() /* kmalloc(, GFP_KERNEL | __GFP_REPEAT) */
    kmalloc_atomic() /* kmalloc(, GFP_ATOMIC) */
    kmalloc_atomic_dma() /* kmalloc(, GFP_ATOMIC | GFP_DMA) */

    an so on? These functions will of course just be static inline
    wrappers for __kmalloc().

    These functions above would just take a size and not confuse
    programmers anymore (as prototypes with compatible arguments
    usally do).

    If it's just a matter of "nobody had the time do do it, yet",
    than this is doable, if only slowly.

    If this is considered nonsense, then I will shut-up.

    What do you think?

    Regards

    Ingo Oeser
    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:34    [W:0.027 / U:0.496 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site