> > If I had my way, _all_ occurances of kfree() would be replaced with
> > kfree_s(). There would be a lot of resistance to this as every consumer
> > would need to know/maintain the size of their allocations. That would
> > make developers think a bit more about their code (good point), but (in
> > some cases) would require an extra field in structures to remember the
> > size (bad point).
Horst von Brand wrote:
> Please don't! Kernel programming is hard enough as it is,
First let me say that while I agree with Mark as a technical point,
I also agree with him that there probably would be too much resistance
to such a major change.
What I don't understand is how you think this is "managing an extra
datum". In the VAST majority of cases there is no extra datum at
run time:
struct foo *p;
p = kmalloc(sizeof(*p), GFP_WHATEVER);
[...]
kfree_s(p, sizeof(*p));
In almost all the cases where the size of the alloc isn't known at compile
time, the code already has to maintain the size itself for other purposes
(think about skb's)
The normal C method invovles tracking down something at run time even
though 99% of the time it's known at compile time. In the few cases it
isn't known at compile time, it's easy to track.
> forcing people to
> manage an extra datum will just invite mistakes, and thus hard to track
> down bugs.
Most of these bugs could easily be found by having a CONFIG_DEBUG_ALLOCSIZE
macro that keeps track of allocation sizes and makes sure that they
match.
> > I've been playing with a new allocation interface, which would extend
> > the current interface, for use by high frequency allocations;
> > kmem_cookie_t cookie;
> > void *objp;
> >
> > cookie = kmalloc_cookie(1024);
> > objp = K_COOKIE_TO_MEM(cookie);
> > ...
> > kfree_cookie(cookie);
> >
> > where K_COOKIE_TO_MEM() is simply a macro.
>
> This is _awful_. Why can't the pointer itself serve as the cookie? People
> _will_ get this wrong all the time!
So just make kmem_cookie_t a non-pointer type and the compiler will happily
catch it 99% of the time. Big deal.
-Mitch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:13 EST