mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Jesper Juhl" <jesper.juhl@gmail.com>
To: "Paul Drynoff" <pauldrynoff@gmail.com>
Cc: "Pekka J Enberg" <penberg@cs.helsinki.fi>,
	akpm@osdl.org, "Linus Torvalds" <torvalds@osdl.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kmalloc man page before 2.6.17
Date: Fri, 26 May 2006 11:48:59 +0200	[thread overview]
Message-ID: <9a8748490605260248i68a1eb84hc241068ae1f012bb@mail.gmail.com> (raw)
In-Reply-To: <36e6b2150605260120s2fb692fegf4fef1eecf7c4674@mail.gmail.com>

On 26/05/06, Paul Drynoff <pauldrynoff@gmail.com> wrote:
> Currently kernel-doc doesn't produce the man page for "kmalloc",
> I think that is a big lack of documentation. This patch should help.
> Now
> scripts/kernel-doc -man -function kmalloc include/linux/slab.h  |
> nroff -man | less
> creates suitable "man page".
>
> Signed-off-by: Paul Drynoff <pauldrynoff@gmail.com>
>
> ---
>
> Index: linux-2.6.17-rc4/mm/slab.c
> ===================================================================
> --- linux-2.6.17-rc4.orig/mm/slab.c
> +++ linux-2.6.17-rc4/mm/slab.c
> @@ -3244,26 +3244,10 @@ EXPORT_SYMBOL(kmalloc_node);
>  #endif
>
>  /**
> - * kmalloc - allocate memory
> + * __do_kmalloc - allocate memory
>   * @size: how many bytes of memory are required.
> - * @flags: the type of memory to allocate.
> + * @flags: the type of memory to allocate(see kmalloc).
>   * @caller: function caller for debug tracking of the caller
> - *
> - * kmalloc is the normal method of allocating memory
> - * in the kernel.
> - *
> - * The @flags argument may be one of:
> - *
> - * %GFP_USER - Allocate memory on behalf of user.  May sleep.
> - *
> - * %GFP_KERNEL - Allocate normal kernel ram.  May sleep.
> - *
> - * %GFP_ATOMIC - Allocation will not sleep.  Use inside interrupt handlers.
> - *
> - * Additionally, the %GFP_DMA flag may be set to indicate the memory
> - * must be suitable for DMA.  This can mean different things on different
> - * platforms.  For example, on i386, it means that the memory must come
> - * from the first 16MB.

You seem to be missing :

   GFP_HIGHUSER
      - Allocate pages from high memory.
   GFP_NOIO
      - Do not do any I/O at all while trying to get memory.
   GFP_NOFS
      - Do not make any fs calls while trying to get memory.

It might also make sense to document the fact that you can set
different flags by OR'ing in one or more of the following :

   __GFP_COLD
      - Request cache-cold pages instead of trying to return cache-warm pages.
   __GFP_DMA
      - Request memory from the DMA-capable zone
   __GFP_HIGH
      - This allocation is high priority and may use emergency pools.
   __GFP_HIGHMEM
      - Allocated memory may be from highmem.
   __GFP_NOFAIL
      - Indicate that this allocation is in no way allowed to fail
(think twice before using).
   __GFP_NORETRY
      - If memory is not imidiately available, then give up at once.
   __GFP_NOWARN
      - If allocation fails, don't issue any warnings.
   __GFP_REPEAT
      - If allocation fails initially, try once more before failing.


Btw: how about vmalloc() do we need to document that one as well
(didn't check) ?


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

  parent reply	other threads:[~2006-05-26  9:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-26  7:07 Paul Drynoff
2006-05-26  7:17 ` Pekka Enberg
2006-05-26  7:58   ` Paul Drynoff
2006-05-26  8:03     ` Pekka J Enberg
2006-05-26  8:20       ` Paul Drynoff
2006-05-26  9:42         ` Andrey Panin
2006-05-26  9:48         ` Jesper Juhl [this message]
2006-05-26 10:44           ` Paul Drynoff
2006-05-26 13:23             ` Paulo Marques
2006-05-26 14:17             ` Christoph Lameter
2006-05-26 14:55               ` Paul Drynoff
2006-05-26 15:03                 ` Christoph Lameter
2006-05-26 19:55             ` Luca
2006-05-27 10:28             ` Martin Waitz
2006-05-26 10:47           ` Paul Drynoff

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=9a8748490605260248i68a1eb84hc241068ae1f012bb@mail.gmail.com \
    --to=jesper.juhl@gmail.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pauldrynoff@gmail.com \
    --cc=penberg@cs.helsinki.fi \
    --cc=torvalds@osdl.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

all inboxes | Powered by JetHome®