From: Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>
To: Andrew Morton <akpm@digeo.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: 2.5.67-mm2
Date: Sun, 13 Apr 2003 15:12:32 +0200 [thread overview]
Message-ID: <20030413151232.D672@nightmaster.csn.tu-chemnitz.de> (raw)
In-Reply-To: <20030412180852.77b6c5e8.akpm@digeo.com>; from akpm@digeo.com on Sat, Apr 12, 2003 at 06:08:52PM -0700
Hi Andrew,
hi lists readers,
On Sat, Apr 12, 2003 at 06:08:52PM -0700, Andrew Morton wrote:
> +gfp_repeat.patch
>
> Implement __GFP_REPEAT: so we can consolidate lots of alloc-with-retry code.
What about reworking the semantics of kmalloc()?
Many users of kmalloc get the flags and size reversed (major
source of hard to find bugs), so wouldn't it be simpler to have:
__kmalloc() /* The old kmalloc()*/
kmalloc() /* kmalloc(, GFP_KERNEL) */
kmalloc_user() /* kmalloc(, GFP_USER) */
kmalloc_dma() /* kmalloc(, GFP_KERNEL | GFP_DMA) */
kmalloc_dma_repeat() /* kmalloc(, GFP_KERNEL | GFP_DMA | __GFP_REPEAT) */
kmalloc_repeat() /* kmalloc(, GFP_KERNEL | __GFP_REPEAT) */
kmalloc_atomic() /* kmalloc(, GFP_ATOMIC) */
kmalloc_atomic_dma() /* kmalloc(, GFP_ATOMIC | GFP_DMA) */
an so on? These functions will of course just be static inline
wrappers for __kmalloc().
These functions above would just take a size and not confuse
programmers anymore (as prototypes with compatible arguments
usally do).
If it's just a matter of "nobody had the time do do it, yet",
than this is doable, if only slowly.
If this is considered nonsense, then I will shut-up.
What do you think?
Regards
Ingo Oeser
--
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:"aart@kvack.org">aart@kvack.org</a>
next prev parent reply other threads:[~2003-04-13 13:12 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-13 1:08 2.5.67-mm2 Andrew Morton
2003-04-13 1:55 ` 2.5.67-mm2 Felipe Alfaro Solana
2003-04-13 3:03 ` 2.5.67-mm2 Jeremy Hall
2003-04-13 3:10 ` 2.5.67-mm2 Andrew Morton
2003-04-13 3:54 ` 2.5.67-mm2 Jeremy Hall
2003-04-13 4:22 ` 2.5.67-mm2 Jeremy Hall
2003-04-13 4:32 ` 2.5.67-mm2 Andrew Morton
2003-04-13 3:14 ` 2.5.67-mm2 William Lee Irwin III
2003-04-13 3:50 ` 2.5.67-mm2 Jeremy Hall
2003-04-13 4:42 ` 2.5.67-mm2 Andrew Morton
2003-04-13 3:17 ` 2.5.67-mm2 Valdis.Kletnieks
2003-04-13 11:15 ` 2.5.67-mm2 Felipe Alfaro Solana
2003-04-13 8:11 ` 2.5.67-mm2 Russell King
2003-04-13 13:12 ` Ingo Oeser [this message]
2003-04-13 14:54 ` 2.5.67-mm2 Arjan van de Ven
2003-04-14 6:24 ` 2.5.67-mm2 Denis Vlasenko
2003-04-14 8:49 ` 2.5.67-mm2 Arjan van de Ven
2003-04-14 17:48 ` 2.5.67-mm2 Joel Becker
2003-04-14 21:31 ` 2.5.67-mm2 Andrew Morton
2003-04-14 21:34 ` 2.5.67-mm2 Randy.Dunlap
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=20030413151232.D672@nightmaster.csn.tu-chemnitz.de \
--to=ingo.oeser@informatik.tu-chemnitz.de \
--cc=akpm@digeo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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