[PATCH 1/1] Fix typos in Documentation/filesystems/seq_file.txt

[Dmitri Vorobiev]

A couple of typos crept into the newly added document
about the seq_file interface. This patch corrects those
typos and simultaneously deletes a few superfluous blanks.

Signed-off-by: Dmitri Vorobiev <dmitri.vorobiev@xxxxxxxxx>
---
 Documentation/filesystems/seq_file.txt |   18 +++++++++---------
 1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/filesystems/seq_file.txt b/Documentation/filesystems/seq_file.txt
index cc6cdb9..2b6aba6 100644
--- a/Documentation/filesystems/seq_file.txt
+++ b/Documentation/filesystems/seq_file.txt
@@ -6,7 +6,7 @@ The seq_file interface
 
 
 There are numerous ways for a device driver (or other kernel component) to
-provide information to the user or system administrator.  One useful
+provide information to the user or system administrator. One useful
 technique is the creation of virtual files, in debugfs, /proc or elsewhere.
 Virtual files can provide human-readable output that is easy to get at
 without any special utility programs; they can also make life easier for
@@ -16,7 +16,7 @@ grown over the years.
 Creating those files correctly has always been a bit of a challenge,
 however. It is not that hard to make a virtual file which returns a
 string. But life gets trickier if the output is long - anything greater
-than an application is likely to read in a single operation.  Handling
+than an application is likely to read in a single operation. Handling
 multiple reads (and seeks) requires careful attention to the reader's
 position within the virtual file - that position is, likely as not, in the
 middle of a line of output. The kernel has traditionally had a number of
@@ -50,7 +50,7 @@ following:
 
 Then concatenate the output files out1 and out2 and get the right
 result. Yes, it is a thoroughly useless module, but the point is to show
-how the mechanism works without getting lost in other details.  (Those
+how the mechanism works without getting lost in other details. (Those
 wanting to see the full source for this module can find it at
 http://lwn.net/Articles/22359/).
 
@@ -92,14 +92,14 @@ implementations; in most cases the start() function should check for a
 "past end of file" condition and return NULL if need be.
 
 For more complicated applications, the private field of the seq_file
-structure can be used. There is also a special value whch can be returned
+structure can be used. There is also a special value which can be returned
 by the start() function called SEQ_START_TOKEN; it can be used if you wish
 to instruct your show() function (described below) to print a header at the
 top of the output. SEQ_START_TOKEN should only be used if the offset is
 zero, however.
 
 The next function to implement is called, amazingly, next(); its job is to
-move the iterator forward to the next position in the sequence.  The
+move the iterator forward to the next position in the sequence. The
 example module can simply increment the position by one; more useful
 modules will do what is needed to step through some data structure. The
 next() function returns a new iterator, or NULL if the sequence is
@@ -146,7 +146,7 @@ the four functions we have just defined:
 This structure will be needed to tie our iterator to the /proc file in
 a little bit.
 
-It's worth noting that the interator value returned by start() and
+It's worth noting that the iterator value returned by start() and
 manipulated by the other functions is considered to be completely opaque by
 the seq_file code. It can thus be anything that is useful in stepping
 through the data to be output. Counters can be useful, but it could also be
@@ -261,13 +261,13 @@ routines useful:
 					loff_t *ppos);
 
 These helpers will interpret pos as a position within the list and iterate
-accordingly.  Your start() and next() functions need only invoke the
-seq_list_* helpers with a pointer to the appropriate list_head structure.  
+accordingly. Your start() and next() functions need only invoke the
+seq_list_* helpers with a pointer to the appropriate list_head structure.
 
 
 The extra-simple version
 
-For extremely simple virtual files, there is an even easier interface.  A
+For extremely simple virtual files, there is an even easier interface. A
 module can define only the show() function, which should create all the
 output that the virtual file will contain. The file's open() method then
 calls:
-- 
1.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/