diff --git a/coding.md b/coding.md index 13f5915a..f5897184 100644 --- a/coding.md +++ b/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. diff --git a/kernel/hal/README.md b/kernel/hal/README.md index 55d2c5fe..8011652c 100644 --- a/kernel/hal/README.md +++ b/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 diff --git a/kernel/proc/README.md b/kernel/proc/README.md index 65496e59..0f8a05d4 100644 --- a/kernel/proc/README.md +++ b/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. diff --git a/kernel/proc/forking.md b/kernel/proc/forking.md index 71e6a4bc..75d86523 100644 --- a/kernel/proc/forking.md +++ b/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, diff --git a/kernel/proc/scheduler.md b/kernel/proc/scheduler.md index 8cc9baa5..c465db42 100644 --- a/kernel/proc/scheduler.md +++ b/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, diff --git a/kernel/vm/README.md b/kernel/vm/README.md index 20a4371b..231972a2 100644 --- a/kernel/vm/README.md +++ b/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 diff --git a/kernel/vm/page.md b/kernel/vm/page.md index 76c0b347..1883c819 100644 --- a/kernel/vm/page.md +++ b/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 diff --git a/libc/functions/f/freopen.part-impl.md b/libc/functions/f/freopen.part-impl.md index a0613469..b20b4e0b 100644 --- a/libc/functions/f/freopen.part-impl.md +++ b/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. diff --git a/libc/functions/s/strlen.part-impl.md b/libc/functions/s/strlen.part-impl.md index 45eb679f..eea737ef 100644 --- a/libc/functions/s/strlen.part-impl.md +++ b/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_. diff --git a/quickstart/README.md b/quickstart/README.md index b959b909..49acd1a8 100644 --- a/quickstart/README.md +++ b/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). diff --git a/quickstart/riscv64-generic-qemu.md b/quickstart/riscv64-generic-qemu.md index 58b4a6db..7e2d7cb8 100644 --- a/quickstart/riscv64-generic-qemu.md +++ b/quickstart/riscv64-generic-qemu.md @@ -42,7 +42,7 @@ Firstly, you need to install QEMU emulator.
- How to get QEMU (Mac OS) + How to get QEMU (macOS) - Install the required packages diff --git a/quickstart/riscv64-generic-spike.md b/quickstart/riscv64-generic-spike.md index 986476a0..8177fc5f 100644 --- a/quickstart/riscv64-generic-spike.md +++ b/quickstart/riscv64-generic-spike.md @@ -86,7 +86,7 @@ Just like before, you first need to install the emulator.
- How to get QEMU (Mac OS) + How to get QEMU (macOS) - Install the required packages diff --git a/tests/README.md b/tests/README.md index 9d73a390..03b738a0 100644 --- a/tests/README.md +++ b/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