Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Nick Piggin <nickpiggin@yahoo.com.au>]

Christoph Lameter wrote:
> On Thu, 30 Nov 2006, Nick Piggin wrote:
> 
> 
>>kmalloc.h uses the slab, and it calls kmem_cache_alloc. How could it be
>>an improvement to not include slab.h? I don't think hiding a data type
>>definition has any value, does it?
> 
> 
> Well you argued yesterday (today?) for hiding struct kmem_cache in a 
> opaque kmem_cache_t. Now its the other way around?

No. I meant that the kmem_cache_t * slab handle that callers get *is*
opaque, as far as they are concerned -- so I wondered what other reasons
there were to remove the typedef.

The enforced hiding of struct kmem_cache is a fun trick, but it is not
something we care about in other parts of the kernel.

> Maybe its best if I just straighten out slab.h (make a segment for the 
> kmalloc material separate from the kmem_cache* functions and try to get 
> the special slob definitions out by defining empty function ins slob.c? 

I don't see the problem with slab/slob. It is not the nicest code, but it
isn't unreadable. We do something very similar with nommu, for (perhaps
not the best!) example.

> That will work for most of slob but not for the kmalloc portions.

But kmalloc seems like one thing that could be split nicely. It would
allow you to get rid of asm/page.h and asm/cache.h from slab.h
(converting callers would be a bigger job).

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>