All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rolf Eike Beer <eike-kernel@sf-tec.de>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: [PATCH][Doc] Add kerneldocs for some functions in mm/memory.c
Date: Tue, 25 Jul 2006 11:03:34 +0200	[thread overview]
Message-ID: <200607251103.34787.eike-kernel@sf-tec.de> (raw)

These functions are already documented quite well with long comments.
Now add kerneldoc style header to make this turn up in everyones favorite
doc format.

Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de>

---
commit 39c068bce1d63f6c1345c1ddfda1841d9fd20c74
tree dbaacbfd0d8049251eb821f7b35d169767044ddf
parent 1bf23f2d14d5e8da05d7ea05505ef92cd780f69f
author Rolf Eike Beer <eike-kernel@sf-tec.de> Tue, 25 Jul 2006 10:58:33 +0200
committer Rolf Eike Beer <beer@siso-eb-i34d.silicon-software.de> Tue, 25 Jul 2006 10:58:33 +0200

 mm/memory.c |   34 +++++++++++++++++++++++++++-------
 1 files changed, 27 insertions(+), 7 deletions(-)


NOTE:

This needs some review. I was searching for a documentation of this 
functions, so what I write down here is what I think to have learned.
Might be slightly or completely wrong.


diff --git a/mm/memory.c b/mm/memory.c
index 109e986..5a8885d 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1226,7 +1226,12 @@ out:
 	return retval;
 }
 
-/*
+/**
+ * vm_insert_page - insert single page into user vma
+ * @vma: user vma to map to
+ * @addr: target user address of this page
+ * @page: source kernel page
+ *
  * This allows drivers to insert individual pages they've allocated
  * into a user vma.
  *
@@ -1318,7 +1323,16 @@ static inline int remap_pud_range(struct
 	return 0;
 }
 
-/*  Note: this is only safe if the mm semaphore is held when called. */
+/**
+ * remap_pfn_range - remap kernel memory to userspace
+ * @vma: user vma to map to
+ * @addr: target user address to start at
+ * @pfn: physical address of kernel memory
+ * @size: size of map area
+ * @prot: page protection flags for this mapping
+ *
+ *  Note: this is only safe if the mm semaphore is held when called.
+ */
 int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
 		    unsigned long pfn, unsigned long size, pgprot_t prot)
 {
@@ -1785,9 +1799,10 @@ void unmap_mapping_range(struct address_
 }
 EXPORT_SYMBOL(unmap_mapping_range);
 
-/*
- * Handle all mappings that got truncated by a "truncate()"
- * system call.
+/**
+ * vmtruncate - unmap mappings "freed" by truncate() syscall
+ * @inode: inode of the file used
+ * @offset: file offset to start truncating
  *
  * NOTE! We have to be ready to update the memory sharing
  * between the file and the memory map for a potential last
@@ -1856,11 +1871,16 @@ int vmtruncate_range(struct inode *inode
 }
 EXPORT_UNUSED_SYMBOL(vmtruncate_range);  /*  June 2006  */
 
-/* 
+/**
+ * swapin_readahead - swap in pages in hope we need them soon
+ * @entry: swap entry of this memory
+ * @addr: address to start
+ * @vma: user vma this addresses belong to
+ *
  * Primitive swap readahead code. We simply read an aligned block of
  * (1 << page_cluster) entries in the swap area. This method is chosen
  * because it doesn't cost us any seek time.  We also make sure to queue
- * the 'original' request together with the readahead ones...  
+ * the 'original' request together with the readahead ones...
  *
  * This has been extended to use the NUMA policies from the mm triggering
  * the readahead.

WARNING: multiple messages have this Message-ID (diff)
From: Rolf Eike Beer <eike-kernel@sf-tec.de>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: [PATCH][Doc] Add kerneldocs for some functions in mm/memory.c
Date: Tue, 25 Jul 2006 11:03:34 +0200	[thread overview]
Message-ID: <200607251103.34787.eike-kernel@sf-tec.de> (raw)

These functions are already documented quite well with long comments.
Now add kerneldoc style header to make this turn up in everyones favorite
doc format.

Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de>

---
commit 39c068bce1d63f6c1345c1ddfda1841d9fd20c74
tree dbaacbfd0d8049251eb821f7b35d169767044ddf
parent 1bf23f2d14d5e8da05d7ea05505ef92cd780f69f
author Rolf Eike Beer <eike-kernel@sf-tec.de> Tue, 25 Jul 2006 10:58:33 +0200
committer Rolf Eike Beer <beer@siso-eb-i34d.silicon-software.de> Tue, 25 Jul 2006 10:58:33 +0200

 mm/memory.c |   34 +++++++++++++++++++++++++++-------
 1 files changed, 27 insertions(+), 7 deletions(-)


NOTE:

This needs some review. I was searching for a documentation of this 
functions, so what I write down here is what I think to have learned.
Might be slightly or completely wrong.


diff --git a/mm/memory.c b/mm/memory.c
index 109e986..5a8885d 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1226,7 +1226,12 @@ out:
 	return retval;
 }
 
-/*
+/**
+ * vm_insert_page - insert single page into user vma
+ * @vma: user vma to map to
+ * @addr: target user address of this page
+ * @page: source kernel page
+ *
  * This allows drivers to insert individual pages they've allocated
  * into a user vma.
  *
@@ -1318,7 +1323,16 @@ static inline int remap_pud_range(struct
 	return 0;
 }
 
-/*  Note: this is only safe if the mm semaphore is held when called. */
+/**
+ * remap_pfn_range - remap kernel memory to userspace
+ * @vma: user vma to map to
+ * @addr: target user address to start at
+ * @pfn: physical address of kernel memory
+ * @size: size of map area
+ * @prot: page protection flags for this mapping
+ *
+ *  Note: this is only safe if the mm semaphore is held when called.
+ */
 int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
 		    unsigned long pfn, unsigned long size, pgprot_t prot)
 {
@@ -1785,9 +1799,10 @@ void unmap_mapping_range(struct address_
 }
 EXPORT_SYMBOL(unmap_mapping_range);
 
-/*
- * Handle all mappings that got truncated by a "truncate()"
- * system call.
+/**
+ * vmtruncate - unmap mappings "freed" by truncate() syscall
+ * @inode: inode of the file used
+ * @offset: file offset to start truncating
  *
  * NOTE! We have to be ready to update the memory sharing
  * between the file and the memory map for a potential last
@@ -1856,11 +1871,16 @@ int vmtruncate_range(struct inode *inode
 }
 EXPORT_UNUSED_SYMBOL(vmtruncate_range);  /*  June 2006  */
 
-/* 
+/**
+ * swapin_readahead - swap in pages in hope we need them soon
+ * @entry: swap entry of this memory
+ * @addr: address to start
+ * @vma: user vma this addresses belong to
+ *
  * Primitive swap readahead code. We simply read an aligned block of
  * (1 << page_cluster) entries in the swap area. This method is chosen
  * because it doesn't cost us any seek time.  We also make sure to queue
- * the 'original' request together with the readahead ones...  
+ * the 'original' request together with the readahead ones...
  *
  * This has been extended to use the NUMA policies from the mm triggering
  * the readahead.

--
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>

             reply	other threads:[~2006-07-25  9:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-25  9:03 Rolf Eike Beer [this message]
2006-07-25  9:03 ` [PATCH][Doc] Add kerneldocs for some functions in mm/memory.c Rolf Eike Beer

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=200607251103.34787.eike-kernel@sf-tec.de \
    --to=eike-kernel@sf-tec.de \
    --cc=akpm@osdl.org \
    --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 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.