At Sat, 6 Aug 2005 17:09:40 +0200,
Adrian Bunk wrote:
>
> On Fri, Aug 05, 2005 at 09:52:32AM +0300, Pekka J Enberg wrote:
> >...
> > --- 2.6.orig/mm/slab.c
> > +++ 2.6/mm/slab.c
> > @@ -2555,6 +2555,20 @@ void kmem_cache_free(kmem_cache_t *cache
> > EXPORT_SYMBOL(kmem_cache_free);
> >
> > /**
> > + * kzalloc - allocate memory. The memory is set to zero.
> > + * @size: how many bytes of memory are required.
> > + * @flags: the type of memory to allocate.
> > + */
> > +void *kzalloc(size_t size, unsigned int __nocast flags)
> > +{
> > + void *ret = kmalloc(size, flags);
> > + if (ret)
> > + memset(ret, 0, size);
> > + return ret;
> > +}
> > +EXPORT_SYMBOL(kzalloc);
> > +
> > +/**
> > * kcalloc - allocate memory for an array. The memory is set to zero.
> > * @n: number of elements.
> > * @size: element size.
> > @@ -2567,10 +2581,7 @@ void *kcalloc(size_t n, size_t size, uns
> > if (n != 0 && size > INT_MAX / n)
> > return ret;
> >
> > - ret = kmalloc(n * size, flags);
> > - if (ret)
> > - memset(ret, 0, n * size);
> > - return ret;
> > + return kzalloc(n * size, flags);
> > }
> > EXPORT_SYMBOL(kcalloc);
>
>
> Looking at how few is left from kcalloc, can't we make it a
> "static inline" function in slab.h?
>
> This would optimize nicely for all of the users where the first or even
> the first two parameters are constant at compile-time and shouldn't do
> much harm for the other users.
>
> As a side effect, the difference between kcalloc(1, ...) and kzalloc()
> would become a coding style question without any effect on the generated
> code.
How about to use __builtin_constant_p() like kmalloc?
The code readability would be worsen, though...
Takashi
-
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/
