> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
