[FE training-materials-updates] Kernel labs: add grammar fixes and rewrites

[Michael Opdenacker]

Repository : git://git.free-electrons.com/training-materials.git

On branch  : master
Link       : http://git.free-electrons.com/training-materials/commit/?id=bec72b36d9196d86f0377bde42f47a3b38e7aa5b

>---------------------------------------------------------------

commit bec72b36d9196d86f0377bde42f47a3b38e7aa5b
Author: Luis Ortega <luiorpe1 at gmail.com>
Date:   Tue May 13 14:49:28 2014 +0200

    Kernel labs: add grammar fixes and rewrites
    
    Signed-off-by: Luis Ortega <luiorpe1 at gmail.com>
    Signed-off-by: Michael Opdenacker <michael.opdenacker at free-electrons.com>


>---------------------------------------------------------------

bec72b36d9196d86f0377bde42f47a3b38e7aa5b
 labs/kernel-board-setup/kernel-board-setup.tex     |    2 +-
 .../kernel-compiling-and-nfs-booting.tex           |    2 +-
 labs/kernel-debugging/kernel-debugging.tex         |    2 +-
 labs/kernel-git/kernel-git.tex                     |    4 ++--
 .../kernel-i2c-communication.tex                   |   10 +++++-----
 .../kernel-i2c-device-model.tex                    |    2 +-
 labs/kernel-module-simple/kernel-module-simple.tex |    2 +-
 labs/kernel-serial-iomem/kernel-serial-iomem.tex   |    2 +-
 labs/kernel-serial-output/kernel-serial-output.tex |   10 +++++-----
 .../kernel-sources-download.tex                    |    4 ++--
 10 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/labs/kernel-board-setup/kernel-board-setup.tex b/labs/kernel-board-setup/kernel-board-setup.tex
index 809de9e..0e8bddf 100644
--- a/labs/kernel-board-setup/kernel-board-setup.tex
+++ b/labs/kernel-board-setup/kernel-board-setup.tex
@@ -196,7 +196,7 @@ tftp 0x81000000 textfile.txt
 \end{verbatim}
 
 {\bf Caution: known issue in Ubuntu 12.04 and later}: if this command
-doesn't work, you may have you have to stop the server and start it
+doesn't work, you may have to stop the server and start it
 again every time you boot your workstation:
 
 \begin{verbatim}
diff --git a/labs/kernel-compiling-and-nfs-booting/kernel-compiling-and-nfs-booting.tex b/labs/kernel-compiling-and-nfs-booting/kernel-compiling-and-nfs-booting.tex
index 717e788..f31dbdd 100644
--- a/labs/kernel-compiling-and-nfs-booting/kernel-compiling-and-nfs-booting.tex
+++ b/labs/kernel-compiling-and-nfs-booting/kernel-compiling-and-nfs-booting.tex
@@ -83,7 +83,7 @@ booting on an NFS exported root directory).
 Compile your kernel.
 
 To boot it on your board with the U-boot bootloader,
-you will to encapsulate the kernel \code{zImage} file
+you will need to encapsulate the kernel \code{zImage} file
 in a special \code{uImage} container for U-boot.
 The kernel \code{Makefile} can generate this container for you by running the
 \code{mkimage} tool found in the \code{uboot-mkimage} package).
diff --git a/labs/kernel-debugging/kernel-debugging.tex b/labs/kernel-debugging/kernel-debugging.tex
index a36e137..9eaa1f5 100644
--- a/labs/kernel-debugging/kernel-debugging.tex
+++ b/labs/kernel-debugging/kernel-debugging.tex
@@ -88,7 +88,7 @@ in a nice way.
 
 Analyze the crash message carefully. Knowing that on ARM, the \code{PC}
 register contains the location of the instruction being executed, find
-in which function does the crash happens, and what the function call
+in which function does the crash happen, and what the function call
 stack is.
 
 Using LXR or the kernel source code, have a look at the definition of this
diff --git a/labs/kernel-git/kernel-git.tex b/labs/kernel-git/kernel-git.tex
index 62cfed5..5e2ba9b 100644
--- a/labs/kernel-git/kernel-git.tex
+++ b/labs/kernel-git/kernel-git.tex
@@ -101,7 +101,7 @@ of git will incite you to make more contributions by yourself.
 
 \section{Tracking another tree}
 
-Say you want to work on the realtime Linux tree, so we'll add this
+Say you want to work on the realtime Linux tree, you'll then add this
 tree to the trees you're tracking:
 
 \small
@@ -112,7 +112,7 @@ git remote add realtime \
 \normalsize
 
 A \code{git fetch} will fetch the data for this tree. Of course, Git
-will optimize the storage, and will no store everything that's common
+will optimize the storage, and will not store everything that's common
 between the two trees. This is the big advantage of having a single
 local repository to track multiple remote trees, instead of having
 multiple local repositories.
diff --git a/labs/kernel-i2c-communication/kernel-i2c-communication.tex b/labs/kernel-i2c-communication/kernel-i2c-communication.tex
index 92e5457..d3b3fbb 100644
--- a/labs/kernel-i2c-communication/kernel-i2c-communication.tex
+++ b/labs/kernel-i2c-communication/kernel-i2c-communication.tex
@@ -33,7 +33,7 @@ and \code{I2C1_SDA}).
 The second step is to open the CPU datasheet (\code{am3359.pdf}), and
 look for pin assignment information ({\em Pin Assignments} section).
 You will find that the processor is available through two types of
-packages: \code{ZCE} and \code{ZCZ}. If you have a very close at the CPU
+packages: \code{ZCE} and \code{ZCZ}. If you have a very close look at the CPU
 (with your glasses on!), you will see that the CPU has \code{ZCZ} written
 on its lower right corner. The BeagleBonne Black Reference Manual also
 confirms this.
@@ -43,9 +43,9 @@ hyperlinks to the descriptions of the \code{A16} and \code{B16} pins.
 That's where you can find reference pin muxing information for these
 pins.  You can find that the pin name for \code{A16} is \code{SPI0_CS0}
 and that the pin name for \code{B16} is \code{SPI0_D1}.
-You can also get a confirm that to obtain the (\code{I2C1_SCL} and
+You can also get confirmation that to obtain the (\code{I2C1_SCL} and
 \code{I2C1_SDA}) signals, you need to configure muxing mode number 2.
-You can also see that pins both support pull-up and pull-down
+You can also see that both pins support pull-up and pull-down
 modes\footnote{See \url{http://en.wikipedia.org/wiki/Pull-up_resistor}}
 (see the \code{PULLUP /DOWN TYPE} column).
 
@@ -173,7 +173,7 @@ scan the \code{i2c1} bus for devices. You should see a device at the
 address \code{0x52}. This is your nunchuk.
 
 If everything works as expected, commit your Device Tree changes. This
-will be required switch to another branch later:
+will be required to switch to another branch later:
 
 \begin{verbatim}
 git commit -as
@@ -231,7 +231,7 @@ errors.
 
 \section{Read nunchuk registers}
 
-The nunchuk exhibits a rather weird behaviour: it seems that it update
+The nunchuk exhibits a rather weird behaviour: it seems that it updates
 the state of its internal registers only when they have been read.
 
 As a consequence, we will need to read the registers twice!
diff --git a/labs/kernel-i2c-device-model/kernel-i2c-device-model.tex b/labs/kernel-i2c-device-model/kernel-i2c-device-model.tex
index 71b0021..37943cb 100644
--- a/labs/kernel-i2c-device-model/kernel-i2c-device-model.tex
+++ b/labs/kernel-i2c-device-model/kernel-i2c-device-model.tex
@@ -85,7 +85,7 @@ modify the \code{arch/arm/boot/dts/am335x-boneblack.dts}
 file to instantiate \code{i2c1}, functioning at 100 KHz.
 For the moment, comment out the \code{pinctrl-} properties.
 They correspond to pin muxing settings for \code{i2c1}. We will define
-these settings in the next lab, and there are not defined in
+these settings in the next lab, and they are not defined in
 any \code{.dtsi} file anyway. 
 
 \subsection{Declare the Nunchuk device} 
diff --git a/labs/kernel-module-simple/kernel-module-simple.tex b/labs/kernel-module-simple/kernel-module-simple.tex
index 20e7eba..e70ab10 100644
--- a/labs/kernel-module-simple/kernel-module-simple.tex
+++ b/labs/kernel-module-simple/kernel-module-simple.tex
@@ -128,7 +128,7 @@ kernel sources. Of course, also modify kernel configuration and
 building files accordingly, so that you can select your module in
 \code{make xconfig} and have it compiled by the \code{make} command.
 
-Run the one of the kernel configuration interfaces and check that it
+Run one of the kernel configuration interfaces and check that it
 shows your new driver lets you configure it as a module.
 
 Run the \code{make} command and make sure that the code of your new
diff --git a/labs/kernel-serial-iomem/kernel-serial-iomem.tex b/labs/kernel-serial-iomem/kernel-serial-iomem.tex
index 83cb53f..c661de7 100644
--- a/labs/kernel-serial-iomem/kernel-serial-iomem.tex
+++ b/labs/kernel-serial-iomem/kernel-serial-iomem.tex
@@ -118,7 +118,7 @@ The next step is to start allocating and registering resources,
 which eventually will have to be freed and unregistered too.
 
 In the same way as in the nunchuk lab, we now need to create a
-structure that that will hold device specific information and help
+structure that will hold device specific information and help
 keeping pointers between logical and physical devices.
 
 As the first thing to store will be the base virtual address for
diff --git a/labs/kernel-serial-output/kernel-serial-output.tex b/labs/kernel-serial-output/kernel-serial-output.tex
index eb8fd99..00dc184 100644
--- a/labs/kernel-serial-output/kernel-serial-output.tex
+++ b/labs/kernel-serial-output/kernel-serial-output.tex
@@ -32,7 +32,7 @@ The first thing to do is to create:
 \item An \code{feserial_write()} write file operation stub.
       See the slides or the code for the prototype to use.
       Just place a \code{return -EINVAL;} statement in the function
-      body so far, to signal that there something wrong with this
+      body so far, to signal that there is something wrong with this
       function so far.
 \item Similarly, an \code{feserial_read()} read file operation stub.
 \item A \code{file_operations} structure declaring these file
@@ -149,7 +149,7 @@ echo "test" > /dev/feserial-48024000
 The \code{test} string should appear on the remote side (i.e in
 the \code{picocom} process connected to \code{/dev/ttyUSB1}).
 
-If it works, you can triumph and do a victory danse in front of the 
+If it works, you can triumph and do a victory dance in front of the
 whole class!
 
 Make sure that both UART devices work on the same way.
@@ -162,7 +162,7 @@ this, when the userspace application sends \verb+"\n"+, you must send
 
 Do it only if you finish ahead of the crowd!
 
-We would like to maintain a counter of the number of characters
+We would like to maintain a count of the number of characters
 written through the serial port. So we need to implement two
 \code{unlocked_ioctl()} operations:
 \begin{itemize}
@@ -170,8 +170,8 @@ written through the serial port. So we need to implement two
  \item \code{SERIAL_RESET_COUNTER}, which as its name says, will
    reset the counter to zero
 
- \item \code{SERIAL_GET_COUNTER}, which will return in a variable
-   passed by address the current value of the counter.
+ \item \code{SERIAL_GET_COUNTER}, which will return the current
+   value of the counter in a variable passed by address.
 
 \end{itemize}
 
diff --git a/labs/kernel-sources-download/kernel-sources-download.tex b/labs/kernel-sources-download/kernel-sources-download.tex
index 038e93c..b8f39da 100644
--- a/labs/kernel-sources-download/kernel-sources-download.tex
+++ b/labs/kernel-sources-download/kernel-sources-download.tex
@@ -69,14 +69,14 @@ cd linux
 git pull
 \end{verbatim}
 
-Of course, if you directly ran \code{git clone}, you won't have run 
+Of course, if you directly ran \code{git clone}, you won't have to run
 \code{git pull} today. You may run \code{git pull} every morning though,
 or at least every time you need an update of the upstream source tree.
 
 \section{Accessing stable releases}
 
 Having the Linux kernel development sources is great, but when you are 
-creating products, you prefer to avoid working with target that moves
+creating products, you prefer to avoid working with a target that moves
 every day.
 
 That's why we need to use the {\em stable} releases of the Linux