Messages in this thread | | | Date | Sat, 6 Aug 2005 17:09:40 +0200 | From | Adrian Bunk <> | Subject | Re: [PATCH] kernel: use kcalloc instead kmalloc/memset |
| |
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.
cu Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
- 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/
| |