> > I wonder why we don't have type safe object allocators a-la new() in > > C++ or g_new() in glib? > > > > fooptr = k_new(struct foo, GFP_KERNEL); > > > > is nicer and more descriptive than > > > > fooptr = kmalloc(sizeof(*fooptr), GFP_KERNEL); > > > > and more safe than > > > > fooptr = kmalloc(sizeof(struct foo), GFP_KERNEL); > > > > And we have zillions of both variants. > > Hmmm yes I think that would be good. However, please clean up the naming. > The variant on zeroing on zering get to be too much.
OK, there seems to be a consensus on that ;) [snip] > I do not see any _node variants? Well, those are _very_ rare, I'd only add those if there's a demand for them. > The array variants translate into kmalloc anyways and are used > in an inconsistent manner. Sometime this way sometimes the other. Leave > them? If the too many variants are bothersome, then I'd rather just have the array variant, and give 1 as an array size for the non-array case. > kcalloc(n, size, flags) == kmalloc(size, flags) > > Then kzalloc is equivalent to adding the __GFP_ZERO flag. Thus > > kzalloc(size, flags) == kmalloc(size, flags | __GFPZERO) > > If you define a new flag like GFP_ZERO_ATOMIC and GFP_ZERO_KERNEL you > could do > > kalloc(struct, GFP_ZERO_KERNEL) > > instead of adding new variants? I don't really like this, introducing new gfp flags just makes grepping harder. I do think that at least having a zeroing and a non-zeroing variant makes sense. Miklos - 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/
