docs: fix mainly some typos

rootless4real · Oct 9, 2018 · e3a82f9 · e3a82f9
1 parent c9f8c21
commit e3a82f9
Show file tree

Hide file tree

Showing 2 changed files with 12 additions and 12 deletions.
diff --git a/docs/QCSuper architecture.md b/docs/QCSuper architecture.md
@@ -33,7 +33,7 @@ The design ease/simplicity tradeoff I have chosen was to use threading (but I'm
 
 QCSuper makes use of different threads:
 
-* The main thread contains the loop reading from the device, and is the only place where reading is performed (it will also dispatch asynchronous messages to modules, calling the `on_log`, `on_message` which may not write neither read, and call at teardown the `on_deinit` callback with may write)
+* The main thread contains the loop reading from the device, and is the only place where reading is performed (it will also dispatch asynchronous messages to modules, calling the `on_log`, `on_message` which may not write neither read, and call at teardown the `on_deinit` callback which may write)
 * A background thread is used for initializing the modules selected through command line arguments (calling the `on_init` callback which may write)
 * A background thread may be used for the optional interactive prompt (`--cli`) and initializing the modules called from it (calling the `on_init` callback which may write)
 
@@ -42,17 +42,17 @@ QCSuper makes use of different threads:
 A module is a Python class which may expose different methods:
 
 * `__init__`: will receive the input object as its first argument, and optionally other arguments from the command line or interactive prompt (passed in sequence from the entry point `qcsuper.py`).
-* `on_init`: called when the connection to the Diag device was established. Not called when the input is not a device but a file containing recorded log data.
+* `on_init`: called when the connection to the Diag device is established. Not called when the input is not a device but a file containing recorded log data.
 * Callbacks triggered by a read on the input source:
-  * `on_log`: called when an asynchronous response Diag protocol raw "log" was received.
-  * `on_message`: called when an asynchronous response Diag protocol text "message" structure was received.
+  * `on_log`: called when an asynchronous response Diag protocol raw "log" is received.
+  * `on_message`: called when an asynchronous response Diag protocol text "message" structure is received.
 * `on_deinit`: called when the connection to the Diag device ceased establishment, or the user hit Ctrl+C.
 
-The methods composing these callback may perform request-response operations (using `self.diag_reader.send_recv(opcode, payload)`, where `self.diag_reader` is the input object).
+The methods composing these callbacks may perform request-response operations (using `self.diag_reader.send_recv(opcode, payload)`, where `self.diag_reader` is the input object).
 
-When a request-response operation is performed, the thread for the callback is paused using the response is received, using a thread synchronization primitive shared with the main thread.
+When a request-response operation is performed, the thread for the callback is paused for the time the response is received, using a thread synchronization primitive shared with the main thread.
 
-When using the interactive prompt (`--cli`), the moment where the `on_init` callbacks ends is the moment where the used is informed that the task continued to background (or is finished, in the case where there is no further callbacks).
+When using the interactive prompt (`--cli`), the moment where the `on_init` callbacks ends is the moment where the user is informed that the task continued to background (or is finished, in the case where there is no further callbacks).
 
 ### Inputs API
 

diff --git a/docs/The Diag protocol.md b/docs/The Diag protocol.md
@@ -2,7 +2,7 @@ The **Diag protocol**, also called **QCDM** or **DM** (Diagnostic monitor) is a
 
 It can be accessed through multiple channels:
 
-* On Android phones, it is exposed internally through the `/dev/diag` device, loaded by the "diagchar" kernel module. This device may communicate with the baseband in multiple ways (shared memory, serial).
+* On Android phones, it is exposed internally through the `/dev/diag` device, created by the "diagchar" kernel module. This device may communicate with the baseband in multiple ways (shared memory, serial).
 
 * On USB modems, it is exposed externally through an USB pseudo-serial port (likely `/dev/ttyUSB*` or `/dev/ttyHSO*`).
   * Most often exposed directly, or requires to send a special AT command (`AT$QCDMG`).
@@ -16,11 +16,11 @@ In its simplest form, the Diag protocol uses a simple framing (inspired by the [
 
 It is composed of:
 
-* Contents in which the trailer character `\x7e` is escaped as `\x7d\x5e`, and `\x7d` escaped as `\x7d\x5d`:
+* Contents in which the trailer character `b\x7e` is escaped as `b\x7d\x5e`, and `b\x7d` escaped as `b\x7d\x5d`:
   * 1 byte: command code
   * n bytes: packet payload
   * 2 bytes: CCITT CRC-16 checksum (with Python: `crcmod.mkCrcFun(0x11021, initCrc=0, xorOut=0xffff)`)
-* 1 byte: trailer character (`\x7e`)
+* 1 byte: trailer character (`b\x7e`)
 
 Looking at the effective contents, these are composed of two parts, the one-byte command code and the payload that ensues.
 
@@ -37,11 +37,11 @@ Diag may expose a lot of functionalites, including:
 * Gathering generation information about the device (baseband firmware version, model, serial number...)
 * Reading/writing memory (fully enabled on older devices, most often restricted to ranges or disabled on newer)
 * Reading/writing non-volatile memory (read and alter protocol-specific state variables)
-* Commands related to calls/SMS
+* Commands related to calls and messaging
 * Commands related to GPS
 * Commands specific to 2G/3G/4G protocols, layer 1 to 3
 * Commands related to the tiny internal filesystem of the baseband (EFS)
-* Many more. Most features added after a some point in the expansion of Diag use the `DIAG_SUBSYS_CMD_F` command which allows to use a 1-byte subsystem number, followed by a 2-bytes subsystem command code.
+* Many more. Most features added after some point in the expansion of Diag use the `DIAG_SUBSYS_CMD_F` command which allows to use a 1-byte subsystem number, followed by a 2-bytes subsystem command code.
 
 # The diag protocol over `/dev/diag`