Messages in this thread | | | Date | Mon, 20 Mar 2006 22:15:29 +0530 | From | "Balbir Singh" <> | Subject | Re: [PATCH] slab: introduce kmem_cache_zalloc allocator |
| |
> No, no, no! I am introducing kmem_cache_zalloc() because there are > existing users in the tree. I plan to kill the slab wrappers from XFS > completely which is why I need this. We already have object constructors > for what you're describing.
Ok, please keep the interface - build kmem_cache_zalloc() on top of what I suggest.
> > On Mon, 2006-03-20 at 21:35 +0530, Balbir Singh wrote: > > This could be used to poison allocated memory. Passing 0 would make > > this equivalent to kmem_cache_zalloc(). Basically, instead of doing > > I am not sure I understand what you mean. We already have slab poisoning > and that's in mm/slab.c. Why would you want to make the callers aware of > that? >
Basically I am not asking for poisoning support as described by slab.c. I am talking about general poisoining. Let me try and further clarify with an example.
Lets say I have a structure resp that is allocated on heap. It is a part of a response structure for a device (say 1394) and is returned by the device to the driver.
When I allocate the structure - I would like to do
kmem_cache_alloc_set(&resp, GFP_XXXXX, 0xEE)
The device should ideally fill all fields of resp. Fields that look 0xEE after receiving the response -- would indicate that they were not filled by the device. This would be extremely useful in debugging. With kmem_cache_zalloc() - 0 is usually almost always a valid value. It is useful in some cases and no so much in other cases.
I could easily achieve the same thing by doing a
memset(&resp, 0xEE, size)
after the kmem_cache_alloc(). But since there is an API to zero out allocated memory, I thought we could make it more generic and more useful.
Lets say we add an API
kmem_cache_alloc_set(cache, flags, byte) { mem = __cache_alloc(...) memset(mem, byte, size) }
we could have
inline kmem_cache_zalloc(cache, flags) { return kmem_cache_alloc_set(cache, flags, 0) }
Balbir - 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/
| |