All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Jones <rob.jones@codethink.co.uk>
To: rdunlap@infradead.org, viro@zeniv.linux.org.uk
Cc: linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-kernel@codethink.co.uk,
	akpm@linux-foundation.org, keescook@chromium.org,
	penguin-kernel@I-love.SAKURA.ne.jp, rob.jones@codethink.co.uk
Subject: [PATCH RESUBMIT 2/2] Documentation/filesystem/seq_file: document seq_open_init()
Date: Wed, 24 Sep 2014 12:15:56 +0100	[thread overview]
Message-ID: <1411557356-10673-3-git-send-email-rob.jones@codethink.co.uk> (raw)
In-Reply-To: <1411557356-10673-1-git-send-email-rob.jones@codethink.co.uk>

Add documentation for new function and restructure existing text
in the same area.

Signed-off-by: Rob Jones <rob.jones@codethink.co.uk>
---
 Documentation/filesystems/seq_file.txt |   58 +++++++++++++++++++++-----------
 1 file changed, 39 insertions(+), 19 deletions(-)

diff --git a/Documentation/filesystems/seq_file.txt b/Documentation/filesystems/seq_file.txt
index 420fc0d..10a3be6 100644
--- a/Documentation/filesystems/seq_file.txt
+++ b/Documentation/filesystems/seq_file.txt
@@ -221,15 +221,37 @@ Here, the call to seq_open() takes the seq_operations structure we created
 before, and gets set up to iterate through the virtual file.
 
 On a successful open, seq_open() stores the struct seq_file pointer in
-file->private_data. If you have an application where the same iterator can
-be used for more than one file, you can store an arbitrary pointer in the
-private field of the seq_file structure; that value can then be retrieved
-by the iterator functions.
+file->private_data.
 
-There is also a wrapper function to seq_open() called seq_open_private(). It
-kmallocs a zero filled block of memory and stores a pointer to it in the
-private field of the seq_file structure, returning 0 on success. The
-block size is specified in a third parameter to the function, e.g.:
+Many applications can use the same iterator for more than one file. You can
+store an arbitrary pointer in the private field of the seq_file structure;
+that value can then be retrieved by the iterator functions.
+
+To facilitate this, a number of wrapper functions to seq_open() are
+provided:
+
++----------------------+---------------------------------------------------------+
+|      Function        | Use case                                                |
++----------------------+---------------------------------------------------------+
+| seq_open()           | Iterator needs no pre-initialised data                  |
+| seq_open_init()      | Iterator needs a pointer to data but no kmalloc needed  |
+| seq_open_private()   | Iterator needs data but kzalloc() suffices              |
+| __seq_open_private() | Iterator needs data with initialisation after kzalloc() |
++----------------------+---------------------------------------------------------+
+
+seq_open_init() is similiar to seq_open() except that it accepts a third
+parameter of type (void *) which it stores in the private field of the
+seq_file structure, e.g.:
+
+	static int ct_open(struct inode *inode, struct file *file)
+	{
+		return seq_open_init(file, &ct_seq_ops, &mystruct);
+	}
+
+seq_open_private() is similar to seq_open_init() except that the third
+parameter is a size. The function kmallocs a zero filled block of memory
+of the supplied size and stores a pointer to this block in the private
+field of the seq_file structure, returning 0 on success, e.g.:
 
 	static int ct_open(struct inode *inode, struct file *file)
 	{
@@ -237,15 +259,14 @@ block size is specified in a third parameter to the function, e.g.:
 					sizeof(struct mystruct));
 	}
 
-There is also a variant function, __seq_open_private(), which is functionally
-identical except that, if successful, it returns the pointer to the allocated
-memory block, allowing further initialisation e.g.:
+__seq_open_private()is a variant of seq_open_private(), functionally
+identical except that, if successful, it returns the pointer to the
+allocated memory block, allowing further initialisation, e.g.:
 
 	static int ct_open(struct inode *inode, struct file *file)
 	{
-		struct mystruct *p =
-			__seq_open_private(file, &ct_seq_ops, sizeof(*p));
-
+		struct mystruct *p;
+		p = __seq_open_private(file, &ct_seq_ops, sizeof(*p));
 		if (!p)
 			return -ENOMEM;
 
@@ -256,9 +277,6 @@ memory block, allowing further initialisation e.g.:
 		return 0;
 	}
 
-A corresponding close function, seq_release_private() is available which
-frees the memory allocated in the corresponding open.
-
 The other operations of interest - read(), llseek(), and release() - are
 all implemented by the seq_file code itself. So a virtual file's
 file_operations structure will look like:
@@ -271,8 +289,10 @@ file_operations structure will look like:
 	        .release = seq_release
 	};
 
-There is also a seq_release_private() which passes the contents of the
-seq_file private field to kfree() before releasing the structure.
+There is also wrapper function, seq_release_private(), which can be used
+instead of seq_release(). It is identical except that it passes the contents
+of the seq_file private field to kfree() before releasing the seq_file
+structure itself.
 
 The final step is the creation of the /proc file itself. In the example
 code, that is done in the initialization code in the usual way:
-- 
1.7.10.4


  parent reply	other threads:[~2014-09-24 11:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-24 11:15 [PATCH RESUBMIT 0/2] fs/seq_file: Add seq_open_init() Rob Jones
2014-09-24 11:15 ` [PATCH RESUBMIT 1/2] fs/seq_file: Create new function seq_open_init() Rob Jones
2014-09-24 21:39   ` Andrew Morton
2014-09-25  9:10     ` Rob Jones
2014-09-25 14:49       ` Randy Dunlap
2014-09-25 17:39         ` Rob Jones
2014-09-25 17:50       ` Andrew Morton
2014-09-25 17:54         ` Rob Jones
2014-09-25 18:07           ` Andrew Morton
2014-09-24 11:15 ` Rob Jones [this message]
2014-09-24 18:06 ` [PATCH RESUBMIT 0/2] fs/seq_file: Add seq_open_init() Kees Cook
2014-09-25  8:57   ` Rob Jones
2014-09-25 16:09     ` Kees Cook
2014-09-25 17:36       ` Rob Jones
2014-09-25 17:40         ` Kees Cook

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=1411557356-10673-3-git-send-email-rob.jones@codethink.co.uk \
    --to=rob.jones@codethink.co.uk \
    --cc=akpm@linux-foundation.org \
    --cc=keescook@chromium.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@codethink.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=rdunlap@infradead.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.