Fix grammar and typos

Author: deantee

.ci/static-analysis.sh

@@ -69,7 +69,7 @@ do_cppcheck()
 
     cppcheck_bin=$(command -v cppcheck || true)
     if [ -z "${cppcheck_bin}" ]; then
-        echo "[!] cppcheck not installed. Failed to run static analysis the source code." >&2
+        echo "[!] cppcheck not installed. Failed to run static analysis on the source code." >&2
         exit 1
     fi
 

README.md

@@ -40,12 +40,12 @@ $ brew install mactex
 $ sudo tlmgr update --self
 ```
 
-Note that `latexmk` is required to generated PDF, and it probably has been installed on your OS already. If not, please follow the [installation guide](https://mg.readthedocs.io/latexmk.html#installation).
+Note that `latexmk` is required to generate PDF, and it probably has been installed on your OS already. If not, please follow the [installation guide](https://mg.readthedocs.io/latexmk.html#installation).
 
-In macOS systems, package `Pygments` may not be pre-installed. If not, please refer to the [installation guide](https://pygments.org/download/) before generate documents.
+In macOS systems, package `Pygments` may not be pre-installed. If not, please refer to the [installation guide](https://pygments.org/download/) before generating documents.
 
 Alternatively, using [Docker](https://docs.docker.com/) is recommended, as it guarantees the same dependencies with our GitHub Actions workflow.
-After install [docker engine](https://docs.docker.com/engine/install/) on your machine, pull the docker image [twtug/lkmpg](https://hub.docker.com/r/twtug/lkmpg) and run in isolated containers.
+After installing [docker engine](https://docs.docker.com/engine/install/) on your machine, pull the docker image [twtug/lkmpg](https://hub.docker.com/r/twtug/lkmpg) and run in isolated containers.
 
 ```shell
 # pull docker image and run it as container
@@ -70,4 +70,4 @@ $ make clean            # Delete generated files
 The Linux Kernel Module Programming Guide is a free book; you may reproduce and/or modify it under the terms of the [Open Software License](https://opensource.org/licenses/OSL-3.0).
 Use of this work is governed by a copyleft license that can be found in the `LICENSE` file.
 
-The complementary sample code is licensed under GNU GPL version 2, as same as Linux kernel.
+The complementary sample code is licensed under GNU GPL version 2, the same as the Linux kernel.

examples/bh_threaded.c

@@ -1,5 +1,5 @@
 /*
- * bh_thread.c - Top and bottom half interrupt handling
+ * bh_threaded.c - Top and bottom half interrupt handling
  *
  * Based upon the RPi example by Stefan Wendler (devnull@kaltpost.de)
  * from:

examples/chardev.h

@@ -21,7 +21,7 @@
 /* _IOW means that we are creating an ioctl command number for passing
  * information from a user process to the kernel module.
  *
- * The first arguments, MAJOR_NUM, is the major device number we are using.
+ * The first argument, MAJOR_NUM, is the major device number we are using.
  *
  * The second argument is the number of the command (there could be several
  * with different meanings).

examples/other/userspace_ioctl.c

@@ -1,8 +1,8 @@
 
-/*  userspace_ioctl.c - the process to use ioctl's to control the kernel module
+/*  userspace_ioctl.c - the process to use ioctls to control the kernel module
  *
  *  Until now we could have used cat for input and output.  But now
- *  we need to do ioctl's, which require writing our own process. 
+ *  we need to do ioctls, which require writing our own process. 
  */
 
 /* device specifics, such as ioctl numbers and the 

examples/procfs2.c

@@ -43,7 +43,7 @@ static ssize_t procfile_read(struct file *file_pointer, char __user *buffer,
     return ret;
 }
 
-/* This function is called with the /proc file is written. */
+/* This function is called when the /proc file is written. */
 static ssize_t procfile_write(struct file *file, const char __user *buff,
                               size_t len, loff_t *off)
 {

examples/procfs4.c

@@ -61,7 +61,7 @@ static int my_seq_show(struct seq_file *s, void *v)
     return 0;
 }
 
-/* This structure gather "function" to manage the sequence */
+/* This structure gathers functions to manage the sequence */
 static struct seq_operations my_seq_ops = {
     .start = my_seq_start,
     .next = my_seq_next,
@@ -75,7 +75,7 @@ static int my_open(struct inode *inode, struct file *file)
     return seq_open(file, &my_seq_ops);
 };
 
-/* This structure gather "function" that manage the /proc file */
+/* This structure gathers functions that manage the /proc file */
 #ifdef HAVE_PROC_OPS
 static const struct proc_ops my_file_ops = {
     .proc_open = my_open,

lkmpg.tex

@@ -1341,7 +1341,7 @@ \subsection{The file\_operations Structure}
 
 An instance of \cpp|struct file_operations| containing pointers to functions that are used to implement \cpp|read|, \cpp|write|, \cpp|open|, \ldots{} system calls is commonly named \cpp|fops|.
 
-Since Linux v3.14, the read, write and seek operations are guaranteed for thread-safe by using the \cpp|f_pos| specific lock, which makes the file position update to become the mutual exclusion.
+Since Linux v3.14, the read, write and seek operations are guaranteed to be thread-safe by using the \cpp|f_pos| specific lock, which makes the file position update to become the mutual exclusion.
 So, we can safely implement those operations without unnecessary locking.
 
 Additionally, since Linux v5.6, the \cpp|proc_ops| structure was introduced to replace the use of the \cpp|file_operations| structure when registering proc handlers.
@@ -1812,8 +1812,8 @@ \section{Talking To Device Files}
 However, this leaves open the question of what to do when you need to talk to the serial port itself, for example to configure the rate at which data is sent and received.
 
 The answer in Unix is to use a special function called \cpp|ioctl| (short for Input Output ConTroL).
-Every device can have its own \cpp|ioctl| commands, which can be read ioctl's (to send information from a process to the kernel), write ioctl's (to return information to a process), both or neither.
-Notice here the roles of read and write are reversed again, so in ioctl's read is to send information to the kernel and write is to receive information from the kernel.
+Every device can have its own \cpp|ioctl| commands, which can be read ioctls (to send information from a process to the kernel), write ioctls (to return information to a process), both or neither.
+Notice here the roles of read and write are reversed again, so in ioctls read is to send information to the kernel and write is to receive information from the kernel.
 
 The ioctl function is called with three parameters: the file descriptor of the appropriate device file, the ioctl number, and a parameter, which is of type long so you can use a cast to use it to pass anything.
 You will not be able to pass a structure this way, but you will be able to pass a pointer to the structure.
@@ -1825,7 +1825,7 @@ \section{Talking To Device Files}
 It is the ioctl number.
 The ioctl number encodes the major device number, the type of the ioctl, the command, and the type of the parameter.
 This ioctl number is usually created by a macro call (\cpp|_IO|, \cpp|_IOR|, \cpp|_IOW| or \cpp|_IOWR| --- depending on the type) in a header file.
-This header file should then be included both by the programs which will use ioctl (so they can generate the appropriate ioctl's) and by the kernel module (so it can understand it).
+This header file should then be included both by the programs which will use ioctl (so they can generate the appropriate ioctls) and by the kernel module (so it can understand it).
 In the example below, the header file is \verb|chardev.h| and the program which uses it is \verb|userspace_ioctl.c|.
 
 If you want to use ioctls in your own kernel modules, it is best to receive an official ioctl assignment, so if you accidentally get somebody else's ioctls, or if they get yours, you'll know something is wrong.
@@ -2010,7 +2010,7 @@ \section{System Calls}
 Without \verb|KASLR|, the attacker may find the target address in the fixed address easily.
 Then the attacker can use return-oriented programming to insert some malicious codes to execute or receive the target data by a tampered pointer.
 \verb|KASLR| mitigates these kinds of attacks because the attacker cannot immediately know the target address, but a brute-force attack can still work.
-If the address of a symbol in \verb|/proc/kallsyms| is different from the address in \verb|/boot/System.map|, \verb|KASLR| is enabled with the kernel, which your system running on.
+If the address of a symbol in \verb|/proc/kallsyms| is different from the address in \verb|/boot/System.map|, \verb|KASLR| is enabled with the kernel, on which your system is running.
 \begin{verbatim}
 $ grep GRUB_CMDLINE_LINUX_DEFAULT /etc/default/grub
 GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
@@ -2389,7 +2389,7 @@ \subsection{Flashing keyboard LEDs}
 If none of the examples in this chapter fit your debugging needs, there might yet be some other tricks to try.
 Ever wondered what \cpp|CONFIG_DEBUG_LL| in \sh|make menuconfig| is good for?
 If you activate that you get low level access to the serial port.
-While this might not sound very powerful by itself, you can patch \src{kernel/printk/printk.c} or any other essential kernel function to print ASCII characters, thus making it possible to trace virtually everything what your code does over a serial line.
+While this might not sound very powerful by itself, you can patch \src{kernel/printk/printk.c} or any other essential kernel function to print ASCII characters, thus making it possible to trace virtually everything that your code does over a serial line.
 If you find yourself porting the kernel to some new and former unsupported architecture, this is usually amongst the first things that should be implemented.
 Logging over a netconsole might also be worth a try.
 
@@ -2889,7 +2889,7 @@ \subsection{Interrupt Handlers}
 To take advantage of them requires handlers to be written in assembly language, so they do not really fit into the kernel.
 They can be made to work similar to the others, but after that procedure, they are no longer any faster than "common" IRQs.
 SMP enabled kernels running on systems with more than one processor need to solve another truckload of problems.
-It is not enough to know if a certain IRQs has happened, it's also important to know what CPU(s) it was for.
+It is not enough to know if a certain IRQ has happened, it's also important to know what CPU(s) it was for.
 People still interested in more details, might want to refer to "APIC" now.
 
 This function receives the IRQ number, the name of the function, flags, a name for \verb|/proc/interrupts| and a parameter to be passed to the interrupt handler.

scripts/Exclude

@@ -1 +1 @@
-Jim Huang,              One of main author
+Jim Huang,              One of the main authors