corrections

coding.md

@@ -126,7 +126,7 @@ Function should be not longer than 200 lines of code and not shorter than 10 lin
 ## Variables
 
 Variables should be named with one short words without the underline characters. If one word is not enough for variable
-name then use camelCase. When defining a variable assign it a value, do not assume that its value is zero. **In the
+name then use camelCase. When defining a variable, assign it a value, do not assume that its value is zero. **In the
 kernel code always initialize global/static variables in runtime.** There's not `.bss` and `.data` initialization in
 the kernel.
 

kernel/hal/README.md

@@ -81,7 +81,7 @@ space is switched.
 
 Timer is the fundamental device for the operating system kernel. It is used for preemptive scheduling and time
 management. HAL is responsible for the implementation of two timers - a scheduler timer and high precision timer.
-On some architectures, they can be based on one hardware device but commonly the are based on two separate devices.
+On some architectures, they can be based on one hardware device, but commonly they are based on two separate devices.
 The interface provided for the upper layer unifies these devices and hides implementation details.
 
 HAL implements one function for operating on timers and defines two interrupt numbers respectively for timers used for

kernel/proc/README.md

@@ -78,8 +78,8 @@ services.
 Virtual addressing and private address spaces have also big impact on memory sharing. When a new process is created it
 can define its private map based on already allocated and named physical memory (see
 [Memory objects](../vm/objects.md)). This map can be derived from the map of parent process or can be established from
-scratch. The smart use of copy-on-write technique allow to allocate the physical memory only for local modifications
-made by process threads during their execution (see [Memory objects](../vm/objects.md)).
+scratch. The smart use of copy-on-write technique allows for the allocation of physical memory only for local
+modifications made by process threads during their execution (see [Memory objects](../vm/objects.md)).
 
 ## Process model on architectures not equipped with MMU
 
@@ -140,7 +140,7 @@ used when MMU is available.
 
 Some address spaces (e.g. kernel address space) can be attributed with the processor execution mode required to
 access to them. Using extended processor execution modes (e.g. ARM TrustZone or IA32 rings) the intermediate privilege
-modes can be introduced. This technique allows to separate the sensitive parts or program executed within a process
+modes can be introduced. This technique allows for separating the sensitive parts or program executed within a process
 from other parts. Privileged and separated address spaces mapped into many processes can consist shared data and code
 used for example for emulation or to implement managed execution environments.
 

kernel/proc/forking.md

@@ -35,8 +35,8 @@ overhead (memory is copied to the child process then is freed and replaced by ne
 In UN*X operating system history "The Mach VM system" added Copy On Write (COW), which made the `fork()` much cheaper,
 and in BSD 4.4, `vfork()` was made synonymous to `fork()`.
 
-`vfork()` function has another important repercussions for non-MMU architectures. Because of semantics it allows to
-launch a new process is the same way as using `fork()` what enables application portability.
+`vfork()` function has another important repercussion for non-MMU architectures. Because of semantics, it allows
+launching a new process in the same way as using `fork()` which enables application portability.
 
 Some consider the semantics of `vfork()` to be an architectural blemish and POSIX.1-2008 removed `vfork()` from the
 standard and replaced by `posix_spawn()`. The POSIX rationale for the `posix_spawn()` function notes that that function,

kernel/proc/scheduler.md

@@ -18,7 +18,7 @@ the same priority. A scheduling algorithm is defined as follows:
 2. The current thread's context for the interrupted core is saved and added to the end of its priority list.
 3. The next available thread with the highest priority is selected to be run and is removed from the ready thread list.
 If a selected thread is a ghost (a thread whose process has ended execution) and has not been executed in a supervisor
-mode, it is added to the ghosts list and the reaper thread is woke up.
+mode, it is added to the ghosts list and the reaper thread is woken up.
 4. For the selected thread, the following actions are performed:
     * A global pointer to the current thread is changed to the selected one,
     * A pointer to the kernel stack is updated to the stack of a new thread,

kernel/vm/README.md

@@ -22,7 +22,7 @@ application demanding minimal jitter (e.g. for signal processing). On multicore
 segment can be tightly coupled with particular set of processing cores while others segments can be accessible over
 switched buses what results in delayed access and performance degradation. Having this in mind in Phoenix-RTOS it was
 decided to redefine the traditional approach to memory management and some new memory management abstractions and
-mechanisms were proposed. These abstractions and mechanisms allow to unify the approach for memory management on many
+mechanisms were proposed. These abstractions and mechanisms allow unifying the approach for memory management on many
 types of memory architectures. To understand the details and purpose of these mechanism memory hardware architecture
 issues are briefly discussed in this chapter before Phoenix-RTOS memory management functions are briefly presented.
 
@@ -120,7 +120,7 @@ parts with different safety requirements.
 Discussion of techniques used for protecting memory when direct physical memory access is used should be complemented by
 presentation of memory segmentation mechanisms popularized widely by x86 microprocessors. The segmentation technique was
 developed on early computers to simplify the program loading and execution process. When a process is to be executed,
-its corresponding segmentation are loaded into non-contiguous memory though every segment is loaded into a contiguous
+its corresponding segmentation is loaded into non-contiguous memory though every segment is loaded into a contiguous
 block of available memory. The location of program segments in physical memory is defined by special set of processor
 registers called segment registers and processor instructions are using offsets calculated according to segment base
 addresses. This technique prevents from using relocation/recalculation of program addresses after it is loaded to memory

kernel/vm/page.md

@@ -141,7 +141,7 @@ Page deallocation is defined as the process opposite to the page allocation proc
 ### Sample deallocation
 
 Let us assume that the page allocated in the previous section must be released. The first step is to analyze the
-neighborhood of the page based on the `pages[]` array. The array is sorted and it is assumed that the
+neighborhood of the page based on the `pages[]` array. The array is sorted, and it is assumed that the
 next page for the released `page_t` is the `page_t` structure, describing the physical page located right
 after the released page or the page located on higher physical addresses. If the next `page_t` structure describes
 the neighboring page, and if it is marked as free, the merging process is performed. The next page is removed from

libc/functions/f/freopen.part-impl.md

@@ -54,7 +54,7 @@ returned, and `errno` shall be set to indicate the error.
 
 The `freopen()` function shall fail if:
 
-* `EACCES` - Search permission is denied on a component of the path prefix, or the file exists and the permissions
+* `EACCES` - Search permission is denied on a component of the path prefix, or the file exists, and the permissions
 specified by _mode_ are denied, or the file does not exist and write permission is denied for the parent directory of
 the file to be created.
 

libc/functions/s/strlen.part-impl.md

@@ -19,7 +19,7 @@ IEEE Std 1003.1-2017
 The `strlen()` function shall compute the number of bytes in the string to which _s_ points, not including the
 terminating `NUL` character.
 The
-`strnlen()` function shall compute the smaller of the number of bytes in the array to which _s_ points, not including
+`strnlen()` function shall compute the smallest of the number of bytes in the array to which _s_ points, not including
 any terminating `NUL` character, or the value of the _maxlen_ argument. The `strnlen()` function shall never examine
 more than _maxlen_ bytes of the array pointed to by _s_.
 

quickstart/README.md

@@ -1,6 +1,6 @@
 # Running system on targets
 
-This chapter presents how to run Phoenix-RTOS on supported targets. It is assumed that `phoenix-rtos-project` is built
+This chapter presents how to run Phoenix-RTOS on supported targets. It is assumed that `phoenix-rtos-project` is built,
 and building artifacts are available in the `_boot` directory. The building process has been described in
 [phoenix-rtos-doc/building](../building/README.md).
 

quickstart/riscv64-generic-qemu.md

@@ -42,7 +42,7 @@ Firstly, you need to install QEMU emulator.
   </details>
 
   <details>
-  <summary>How to get QEMU (Mac OS)</summary>
+  <summary>How to get QEMU (macOS)</summary>
 
 - Install the required packages
 

quickstart/riscv64-generic-spike.md

@@ -86,7 +86,7 @@ Just like before, you first need to install the emulator.
   </details>
 
   <details>
-  <summary>How to get QEMU (Mac OS)</summary>
+  <summary>How to get QEMU (macOS)</summary>
 
 - Install the required packages
 

tests/README.md

@@ -478,12 +478,12 @@ Now let's go through the tests and try to understand the final configuration:
 
 - The `arg_zero` test specifies that the `test-hello-arg` executable should be executed without any arguments
 (`execute: test-hello-arg`). We provide the `hello_arg_harness.py` as the harness. In the `kwargs` section, we set
-`argc` to `0`. This dictionary is passed later to the harness as `kwargs` parameter. Additional, we exclude the
+`argc` to `0`. This dictionary is passed later to the harness as `kwargs` parameter. Additionally, we exclude the
 `armv7a9-zynq7000-qemu` target for this specific test. As a result, it will be run on the `ia32-generic-qemu` and
 `host-generic-pc` targets.
 - The `arg_two` test specifies that the `test-hello-arg` should be executed with two arguments: `arg1` and `arg2`
 (`execute: test-hello-arg arg1 arg2`). We provide the `hello_arg_harness.py` as the harness. In the `kwargs` section, we
-set `argc` to `2`. Additional, we specify that this test should only run on the `ia32-generic-qemu` target.
+set `argc` to `2`. Additionally, we specify that this test should only run on the `ia32-generic-qemu` target.
 - The `arg_hello` test specifies that the `test-hello-arg` executable should be executed with the argument `world`. We
 provide the `hello_arg_harness.py` as the harness. In the `kwargs` section, we set `input` to `Adios!`. This word will
 be used as the input to the `test-hello-arg`. We also set `nightly` to false for this specific test. Thanks to that, the