From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Christoph Hellwig <hch@infradead.org>
Cc: Christoph Lameter <clameter@sgi.com>,
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: Wed, 29 Nov 2006 19:38:58 +1100 [thread overview]
Message-ID: <456D4722.2010202@yahoo.com.au> (raw)
In-Reply-To: <20061129082650.GB12734@infradead.org>
Christoph Hellwig wrote:
> On Mon, Nov 27, 2006 at 10:33:28PM -0800, Christoph Lameter wrote:
>
>>slab.h really defines multiple APIs. One is the classic slab api
>>where one can define a slab cache by specifying exactly how
>>the slab has to be generated. This API is not frequently used.
>>
>>Another is the kmalloc API. Quite a number of kernel source code files
>>need kmalloc but do not need to generate custom slabs. The kmalloc API
>>also use some funky macros that may be better isolated in an additional .h
>>file in order to ease future cleanup. Make kmalloc.h self contained by
>>adding two extern definitions local to kmalloc and kmalloc_node.
>>
>>Then there is the SLOB api mixed in with slab. Take that out and define it
>>in its own header file.
>
>
> 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?
It does seem wrong, I agree. For another thing, there is no "slob API".
Slob is an implementation of the *slab API*.
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.
--
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-29 8:38 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 [this message]
2006-11-29 19:24 ` Christoph Lameter
2006-11-30 1:58 ` Nick Piggin
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=456D4722.2010202@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox