From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: MTD mailing list <linux-mtd@lists.infradead.org>
Subject: [PATCH] Web site: Some grammatical fixes for the FAQ General page.
Date: Tue, 9 Feb 2010 08:44:56 -0500 (EST) [thread overview]
Message-ID: <alpine.LFD.2.00.1002090844070.8655@localhost> (raw)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
---
diff --git a/faq/general.xml b/faq/general.xml
index 81ba994..1c0551f 100644
--- a/faq/general.xml
+++ b/faq/general.xml
@@ -79,7 +79,7 @@ also block devices.</P>
<TABLE cellpadding="5" cellspacing="0" border="1">
<TR>
- <TD><B>Block drives</B></TD>
+ <TD><B>Block device</B></TD>
<TD><B>MTD device</B></TD>
</TR>
<TR>
@@ -104,7 +104,7 @@ also block devices.</P>
<TD>
Bad sectors are re-mapped and hidden by hardware (at
least in modern LBA hard drives); in case of FTL
- devices it is the resposibility of FTL to provide this
+ devices it is the responsibility of FTL to provide this
</TD>
<TD>
Bad eraseblocks are not hidden and should be dealt with
@@ -164,7 +164,7 @@ device nodes.
<P>
But in many cases using <CODE>mtdblock</CODE> is a very bad idea because what
-it basically does if you change any sector of you mtdblockX device, it reads
+it basically does if you change any sector of your mtdblockX device, it reads
the whole corresponding eraseblock into the memory, erases the eraseblock,
changes the sector in RAM, and writes the whole eraseblock back. This is very
straightforward. If you have a power failure when the eraseblock is being
@@ -183,7 +183,7 @@ UBI.
<P>
It makes sense to use <CODE>mtdblock_ro</CODE> for read-only file systems or
read-only mounts. For example, one may use SquashFS as it compresses data quite
-well. But think twice before using <CODE>mtdblock</CODE> in read-write more.
+well. But think twice before using <CODE>mtdblock</CODE> in read-write mode.
And don't try to use it on NAND flash as it is does not handle bad
eraseblocks.
</P>
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
next reply other threads:[~2010-02-09 13:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-09 13:44 Robert P. J. Day [this message]
2010-02-16 7:58 ` [PATCH] Web site: Some grammatical fixes for the FAQ General page 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=alpine.LFD.2.00.1002090844070.8655@localhost \
--to=rpjday@crashcourse.ca \
--cc=linux-mtd@lists.infradead.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