From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Christoph Lameter <clameter@sgi.com>
Cc: Christoph Hellwig <hch@infradead.org>,
akpm@osdl.org, linux-mm@kvack.org,
Pekka Enberg <penberg@cs.helsinki.fi>,
mpm@selenic.com, Manfred Spraul <manfred@colorfullife.com>
Subject: Re: [RFC] Extract kmalloc.h and slob.h from slab.h
Date: Thu, 30 Nov 2006 12:58:38 +1100 [thread overview]
Message-ID: <456E3ACE.4040804@yahoo.com.au> (raw)
In-Reply-To: <Pine.LNX.4.64.0611291119480.16189@schroedinger.engr.sgi.com>
Christoph Lameter wrote:
> On Wed, 29 Nov 2006, Nick Piggin wrote:
>
>
>>>NACK. This is utterly braindead, easily shown by things like the need
>>>to duplicate the kmem_cache_alloc prototype.
>>>
>>>What are you trying to solve with this?
>
>
> I am trying to detangle various things in the slab. Its a bit complex.
>
>
>>It does seem wrong, I agree. For another thing, there is no "slob API".
>>Slob is an implementation of the *slab API*.
>
>
> But the definitions vary a lot. Should I try to find the common
> function declarations and keep them together?
The point is that it *is the same API*. Having the declarations for the slob
implementation in slob.h, and then including slab.h in slob.h seems completely
backwards.
I don't see that breaking them out gains you very much at all, but if you do
want to, then I'd rather have slob_defs.h and slab_defs.h, then have slab.h
include either one depending on the config.
>>kmalloc seems OK to be split. But given that it is built on top of the
>>slab, then it should not be going out of its way to avoid the slab.h
>>include, as Christoph H points out.
>>
>>If this whole exercise is to dispense with a few includes, then I'll
>>second Christoph's nack. This kinds of tricks does not make it easier
>>to untangle and redesign header dependencies properly in the long term.
>
>
> Right now the slab.h is difficult to understand. Separating things out
> will make the .h files small and nicely focused on one thing.
>
> We have some ugly things in kmalloc.h like the include of kmalloc_sizes.h
> and the CACHE definitions. I think those should be separated and then
> hopefully we can fix this up at some point.
>
> Having kmalloc.h separate will also help if we put the definition of
> struct kmem_cache in slab.c. Then the definition will be hidden from the
> simple kmalloc users.
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?
Other than that, I don't have any problem with moving kmalloc to its own
header.
--
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>
next prev parent reply other threads:[~2006-11-30 1:58 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-28 6:33 [RFC] Extract kmalloc.h and slob.h from slab.h Christoph Lameter
2006-11-28 8:00 ` Pekka Enberg
2006-11-28 18:05 ` Christoph Lameter
2006-11-28 19:07 ` Pekka J Enberg
2006-11-28 19:11 ` Christoph Lameter
2006-11-28 19:19 ` Pekka J Enberg
2006-11-28 19:24 ` Pekka Enberg
2006-11-28 19:27 ` Christoph Lameter
2006-11-28 19:25 ` Christoph Lameter
2006-11-28 19:32 ` Pekka Enberg
2006-11-28 19:53 ` Christoph Lameter
2006-11-29 0:30 ` Christoph Lameter
2006-11-29 7:08 ` Pekka Enberg
2006-11-29 19:18 ` Christoph Lameter
2006-11-29 8:26 ` Christoph Hellwig
2006-11-29 8:38 ` Nick Piggin
2006-11-29 19:24 ` Christoph Lameter
2006-11-30 1:58 ` Nick Piggin [this message]
2006-11-30 2:43 ` Christoph Lameter
2006-11-30 3:04 ` Nick Piggin
2006-11-30 3:39 ` Christoph Lameter
2006-11-30 3:44 ` Nick Piggin
2006-11-30 3:50 ` Christoph Lameter
2006-11-30 4:18 ` Nick Piggin
2006-11-30 4:28 ` Christoph Lameter
2006-11-30 5:01 ` Nick Piggin
2006-11-30 7:12 ` Pekka Enberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=456E3ACE.4040804@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=clameter@sgi.com \
--cc=hch@infradead.org \
--cc=linux-mm@kvack.org \
--cc=manfred@colorfullife.com \
--cc=mpm@selenic.com \
--cc=penberg@cs.helsinki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.