linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Brian Norris" <norris@broadcom.com>
To: "pjohn@mvista.com" <pjohn@mvista.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH] mtd-www doc, FAQ, general: spelling fixes
Date: Thu, 24 Jun 2010 09:41:48 -0700	[thread overview]
Message-ID: <4C238ACC.8050004@broadcom.com> (raw)
In-Reply-To: <1277387522.24980.6.camel@localhost.localdomain>

On 06/24/2010 06:52 AM, Philby John wrote:

> 
>>   Probably because you flash is too small? Try to use JFFS2 then, becasue it
>                      ^^^                                            ^^^^^
> You missed "you", should be "your", and "becasue".
> 
> Regards,
> Philby
> 
> 

Thanks. Here's just a couple more missed edits.

Signed-off-by: Brian Norris <norris@broadcom.com>
---
 faq/jffs2.xml |    4 ++--
 faq/ubifs.xml |   14 +++++++-------
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/faq/jffs2.xml b/faq/jffs2.xml
index 1bc8680..a08af7a 100644
--- a/faq/jffs2.xml
+++ b/faq/jffs2.xml
@@ -277,8 +277,8 @@ There are two cases where this does not work. The first is when JFFS2 is used
 as a root filesystem. For now, this requires the mtdblock device to be
 specified for <CODE>root=</CODE> on the kernel command line. The second case is
 when the mount binary that is being used does not play nicely with the above
-format. The busybox version of mount is known to not work without the mtdblock
-device.
+format. The BusyBox version of <CODE>mount</CODE> is known to not work without
+the mtdblock device.
 </P>
 
 
diff --git a/faq/ubifs.xml b/faq/ubifs.xml
index 9dd5d3d..ea371f6 100644
--- a/faq/ubifs.xml
+++ b/faq/ubifs.xml
@@ -33,8 +33,8 @@
 	<li><a href="ubifs.html#L_ubifs_extract">How do I extract files from an UBI/UBIFS image?</a></li>
 	<li><a href="ubifs.html#L_powercut">Is UBIFS tolerant to power-cuts?</a></li>
 	<li><a href="ubifs.html#L_smaller_jrn">I need more space - should I make UBIFS journal smaller?</a></li>
-	<li><a href="ubifs.html#L_empty_file">Why my file is empty after an unclean reboot?</a></li>
-	<li><a href="ubifs.html#L_end_hole">Why my file has zeroes at the end after an unclean reboot?</a></li>
+	<li><a href="ubifs.html#L_empty_file">Why is my file empty after an unclean reboot?</a></li>
+	<li><a href="ubifs.html#L_end_hole">Why does my file have zeroes at the end after an unclean reboot?</a></li>
 	<li><a href="ubifs.html#L_bgt_thread">What does the "ubifs_bgt0_0" thread do?</a></li>
 	<li><a href="ubifs.html#L_sudden_ro">UBIFS suddenly became read-only - what is this?</a></li>
 	<li><a href="ubifs.html#L_detect_ro">How do I detect if UBIFS became read-only?</a></li>
@@ -986,12 +986,12 @@ size.</p>
 
 <p>To put it simple, the amount of available space on UBIFS does not really
 depend on the journal size. There is very weak dependency, though, because for
-bigger journal we need bigger log, but it is really something which does not
-make any noticeable difference.</p>
+a bigger journal we need a bigger log, but it really does not make a
+noticeable difference.</p>
 
 
 
-<h2><a name="L_empty_file">Why my file is empty after an unclean reboot?</a></h2>
+<h2><a name="L_empty_file">Why is my file empty after an unclean reboot?</a></h2>
 
 <p>Zero-length files are a special case of corruption which happens when
 an application first truncates a file, then updates it. The truncation is
@@ -1048,7 +1048,7 @@ to implement it.</p>
 
 
 
-<h2><a name="L_end_hole">Why my file has zeroes at the end after an unclean reboot?</a></h2>
+<h2><a name="L_end_hole">Why does my file have zeroes at the end after an unclean reboot?</a></h2>
 
 <p>Power cuts often lead to holes at the end of files. Holes are areas of
 the file which contain no data. For example, if you truncate a file to a larger
@@ -1176,7 +1176,7 @@ I get: "init_constants_early: too few LEBs (12), min. is 17"
 </a></h2>
 
 <p>This error means that you are trying to mount too small UBI volume.
-Probably because you flash is too small? Try to use JFFS2 then, becasue it
+Probably because your flash is too small? Try to use JFFS2, then, because it
 suits small flashes better since it has much lower space overhead. Indeed,
 UBIFS stores much more indexing information on the flash media than JFFS2, so
 it has much higher overhead. Also, UBI has some overhead (see
-- 
1.7.1

  reply	other threads:[~2010-06-24 16:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-23 22:42 [PATCH] mtd-www doc, FAQ, general: spelling fixes Brian Norris
2010-06-24 13:52 ` Philby John
2010-06-24 16:41   ` Brian Norris [this message]
2010-07-08  9:24     ` Artem Bityutskiy
2010-07-08 22:23       ` Brian Norris
2010-07-18  7:24         ` Artem Bityutskiy
2010-07-13  8:10 ` Artem Bityutskiy

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=4C238ACC.8050004@broadcom.com \
    --to=norris@broadcom.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=pjohn@mvista.com \
    /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;
as well as URLs for NNTP newsgroup(s).