Fix typos in Architecture chapter (#97)

Author: hannahfluch

02_Architecture/01_Overview.md

@@ -4,31 +4,31 @@ Before going beyond a basic "hello world" and implementing the first real parts
 
 It's worth noting that we're going to focus exclusively on `x86_64` here, and some concepts are specific to this platform (the GDT, for example), while some concepts are transferable across most platforms (like a higher half kernels). Some, like interrupts and interrupt handlers, are only partially transferable to other platforms.
 
-Similarly to the previous part, this chapter will be an high level introduction of the concept that will be explained later.
+Similarly to the previous part, this chapter will be a high level introduction of the concept that will be explained later.
 
 The [Hello World](02_Hello_World.md) chapter will guide through the implementation of some basic _serial i/o_ functions to be used mostly for debugging purpose (especially with an emulator), we will see how to send characters, strings and how to read them.
 
 Many modern operating systems place their kernel in the _Higher Half_ of the virtual memory space, what it is, and how to place the kernel there is explained in the [Higher Half](03_Higher_Half.md) chapter.
 
 In the [GDT](04_GDT.md) we will explain one of the `x86` structures used to _describe_ the memory to the CPU, although is a legacy structures its usage is still required in several part of the kernel (especially when dealing with userspace)
 
-Then the chapters [Interrup Handling](05_InterruptHandling.md), [ACPI Tables](06_AcpiTables.md) and [APIC](07_APIC.md) will discuss how the `x86` cpu handle the exceptions and interrupts, and how the kernel should deal with them.
+Then the chapters [Interrupt Handling](05_InterruptHandling.md), [ACPI Tables](06_AcpiTables.md) and [APIC](07_APIC.md) will discuss how the `x86` cpu handle the exceptions and interrupts, and how the kernel should deal with them.
 
 The [Timers](08_Timers.md) chapter will use one of the Interrupts handling routines to interrupt the kernel execution at regular intervals, this will be the ground for the implementation of the multitasking in our kernel.
 
-The final three chapters of this part: [PS2 Keyboard Overview](09_Add_Keyboard_Support.md), [PS2 Keybord Interrupt Handling](10_Keyboard_Interrupt_Handling.md), [PS2 Keyboard Driver implementation](11_Keyboard_Driver_Implemenation.md) will explain how a keyboard work, what are the scancodes, how to translate them into character, and finally describe the steps to implement a basic keyboard driver.
+The final three chapters of this part: [PS2 Keyboard Overview](09_Add_Keyboard_Support.md), [PS2 Keyboard Interrupt Handling](10_Keyboard_Interrupt_Handling.md), [PS2 Keyboard Driver implementation](11_Keyboard_Driver_Implemenation.md) will explain how a keyboard work, what are the scancodes, how to translate them into character, and finally describe the steps to implement a basic keyboard driver.
 
 ## Address Spaces
 
-If we've never programmed at a low level before, we'll likely only dealt with a single address space: the virtual address space the program lives in. However there are actually many other address spaces to be aware of!
+If we've never programmed at a low level before, we'll likely only deal with a single address space: the virtual address space the program lives in. However, there are actually many other address spaces to be aware of!
 
 This brings up the idea that an address is only useful in a particular address space. Most of the time we will be using virtual addresses, which is fine before our program lives in a virtual address space, but at times we will use *physical addresses* which, as we might have guessed, deal with the physical address space.
 
 These are not the same, as we'll see later on we can convert virtual addresses to physical addresses (usually the cpu will do this for us), but they are actually separate things.
 
 There are also other address spaces we may encounter in osdev, like:
 
-- Port I/O: Some older devices on x86 are wired up to 'ports' on the cpu, with each port being given an address. These addresses are not virtual or physical memory addresses, so we can't access them like pointers. Instead special cpu instructions are used to move in and out of this address space.
+- Port I/O: Some older devices on x86 are wired up to 'ports' on the cpu, with each port being given an address. These addresses are not virtual or physical memory addresses, so we can't access them like pointers. Instead, special cpu instructions are used to move in and out of this address space.
 - PCI Config Space: PCI has an entirely separate address that for configuring devices. This address space has a few different ways to access it.
 
 Most of the time we won't have to worry about which address space to deal with: hardware will only deal with physical addresses, and the code will mostly deal with virtual addresses. As mentioned earlier we'll later look at how we use both of these so don't worry!
@@ -49,7 +49,7 @@ It's easy to be overwhelmed by the number of fields in the GDT, but most modern
 
 The currently active descriptors tell the CPU what mode it is in: if a user code descriptor is loaded - it's running user-mode code. Data descriptors tell the CPU what privilege level to use when we access memory, which interacts with the user/supervisor bit in the page tables (as we'll see later).
 
-If unsure where to start, we'll need a 64-bit kernel code descriptor and 64-bit kernel data descriptor at the bare mimimum.
+If unsure where to start, we'll need a 64-bit kernel code descriptor and 64-bit kernel data descriptor at the bare minimum.
 
 ## How The CPU Executes Code
 
@@ -63,7 +63,7 @@ These things can happen at any time, and as the operating system kernel we would
 
 When an unexpected event happens, the cpu will immediately stop the current code it's running and start running a special function called an *interrupt handler*. The interrupt handler is something the kernel tells the cpu about, and the function can then work out what event happened, and then take some action. The interrupt handler then tells the cpu when it's done, and then cpu goes back to executing the previously running code.
 
-The interrupted code is usually never aware that an interrupt even ocurred, and should continue on as normal.
+The interrupted code is usually never aware that an interrupt even occurred, and should continue on as normal.
 
 ## Drivers
 

02_Architecture/02_Hello_World.md

@@ -1,6 +1,6 @@
 # Hello World
 
-During the development of our kernel we will need to debug a lot, and checking a lot of values, but so far our kernel is not capable of doing anything, and having proper video output with scrolling, fonts etc, can take some time, so we need a quick way of getting some text out from our kernel, not necessarily on the screen. 
+During the development of our kernel we will need to debug a lot, and checking a lot of values, but so far our kernel is not capable of doing anything, and having proper video output with scrolling, fonts etc., can take some time, so we need a quick way of getting some text out from our kernel, not necessarily on the screen. 
 
 This is where the serial logging came to an aid, we will use the serial port to output our text and numbers. 
 
@@ -14,13 +14,13 @@ This will save the serial output on the file called `filename.log`, if we want t
 
 ## Printing to Serial
 
-We will use the `inb` and `outb` instruction to communicate with the serial port. But the first thing our kernel should do is do is being able to write to serial ports. To do that we need: 
+We will use the `inb` and `outb` instruction to communicate with the serial port. But the first thing our kernel should do is being able to write to serial ports. To do that we need: 
 
-* for simiplicity and readability two C functions that will make use of the inb/outb asm instructions (luckily they are asm functions so making their c version is very easy)
+* for simplicity and readability two C functions that will make use of the inb/outb asm instructions (luckily they are asm functions so making their c version is very easy)
 * initialization of serial communication
 * and at least an instruction to send characters and strings to the serial. 
 
-The first step is pretty strightforward, using inline assembly we will create two "one-line" functions for inb and outb: 
+The first step is pretty straightforward, using inline assembly we will create two "one-line" functions for inb and outb: 
 
 ```C
 extern inline unsigned char inportb (int portnum)
@@ -69,7 +69,7 @@ static int init_serial() {
 }
 ```
 
-Notice that usually the com1 port is mapped to address: *0x3f8*. The function above is setting just default values for serial communication. An alternative that does not require any initialization is to use the port `0xe9`, this is also know as the _debugcon_ or the _port e9 hack_ and it still use the `inportb` and `outportb` functions as they are, but is often faster because is a special port that sends data directly to the emulator console output. 
+Notice that usually the com1 port is mapped to address: *0x3f8*. The function above is setting just default values for serial communication. An alternative that does not require any initialization is to use the port `0xe9`, this is also known as the _debugcon_ or the _port e9 hack_, and it still uses the `inportb` and `outportb` functions as they are, but is often faster because is a special port that sends data directly to the emulator console output. 
 
 ### Sending a string
 
@@ -105,9 +105,9 @@ As an example consider the number 1235:  $1235/10=123.5$ and $1235 \mod 10=5$, r
 * $12/10 = 1$ and $12 \mod10 = 2$
 * $1/10 = 0$  and $1 \mod 10 = 1$
 
-And as we can see we got all the digits in reverse order, so now the only thing we need to do is reverse the them. The implementation of this function should be now pretty straightforward, and it will be left as exercise. 
+And as we can see we got all the digits in reverse order, so now the only thing we need to do is reverse them. The implementation of this function should be now pretty straightforward, and it will be left as exercise. 
 
-Printing other format like Hex or Octal is little bit different, but the base idea of getting the single number and converting it into a character is similar. The only tricky thing with the hex number is that now we have symbols for numbers between 10 and 15 that are characters, and they are before the digits symbol in the ascii map, but once that is known it is going to be just an if statement in our function. 
+Printing other format like Hex or Octal is a little bit different, but the base idea of getting the single number and converting it into a character is similar. The only tricky thing with the hex number is that now we have symbols for numbers between 10 and 15 that are characters, and they are before the digits symbol in the ascii map, but once that is known it is going to be just an if statement in our function. 
 
 ### Troubleshooting
 

02_Architecture/04_GDT.md

@@ -11,14 +11,14 @@ Most descriptors are 8 bytes wide, usually resulting in the selectors looking li
 - null descriptor: selector 0x0
 - first descriptor: selector 0x8
 - second descriptor: selector 0x10
-- third descritor: selector 0x18
+- third descriptor: selector 0x18
 - etc ...
 
 There is one exception to the 8-byte-per-descriptor rule, the TSS descriptor, which is used by the `ltr` instruction to load the task register with a task state segment. It's a 16-byte wide descriptor.
 
 Usually these selectors are for code (CS) and data (DS, SS), which tell the cpu where it's allowed to fetch instructions from, and what regions of memory it can read/write to. There are other selectors, for example the first entry in the GDT must be all zeroes (called the null descriptor).
 
-The null selector is mainly used for edge cases, and is usually treated as 'ignore segmentation', although it can lead to #GP faults if certain instructions are issued. Its usage only occurs with more advanced parts of x86, so we'll known to look out for it.
+The null selector is mainly used for edge cases, and is usually treated as 'ignore segmentation', although it can lead to #GP faults if certain instructions are issued. Its usage only occurs with more advanced parts of x86, so we'll know to look out for it.
 
 The code and data descriptors are what they sound like: the code descriptor tells the cpu what region of memory it can fetch instructions from, and how to interpret them. Code selectors can be either 16-bit or 32-bit, or if running in long mode 64-bit or 32-bit.
 
@@ -48,13 +48,13 @@ The various segment registers:
 - _FS_: F selector, no specific purpose. Sys V ABI uses it for thread local storage.
 - _GS_: G selector, no specific purpose. Sys V ABI uses it for process local storage, commonly used for cpu-local storage in kernels due to `swapgs` instruction.
 
-When using a selector to refer to a GDT descriptor, we'll also need to specify the ring we're trying to access. This exists for legacy reasons to solve a few edge cases that have been solved in other ways. If we will need to use these mechanisms, we'll know, otherwise the default (setting to zero) is fine.
+When using a selector to refer to a GDT descriptor, we'll also need to specify the ring we're trying to access. This exists for legacy reasons to solve a few edge cases that have been solved in other ways. If we need to use these mechanisms, we'll know, otherwise the default (setting to zero) is fine.
 
 A _segment selector_ contains the following information:
 
 * `index` bits 15-3: is the GDT selector.
 * `TI` bit 2: is the Table Indicator if clear it means GDT, if set it means LDT, in our case we can leave it to 0.
-* `RPL` bits 1 and 0:  is the Requested Priivlege Level, it will be explained later.
+* `RPL` bits 1 and 0:  is the Requested Privilege Level, it will be explained later.
 
 
 Constructing a segment selector is done like so:
@@ -69,7 +69,7 @@ selector |= ((is_ldt_selector & 0b1) << 2);
 
 The `is_ldt_selector` field can be set to tell the cpu this selector references the LDT (local descriptor table) instead of the GDT. We're not interested in the LDT, so we will leave this as zero. The `target_cpu_ring` field (called RPL in the manuals), is used to handle some edge cases. This is best set to the same ring the selector refers to (if the selector is for ring 0, set this to 0, if the selector is for ring 3, set this to 3).
 
-It's worth noting that in the early stages of the kernel we only be using the GDT and kernel selectors, meaning these fields are zero. Therefore this calculation is not necessary, we can simply use the byte offset into the GDT as the selector.
+It's worth noting that in the early stages of the kernel we only be using the GDT and kernel selectors, meaning these fields are zero. Therefore, this calculation is not necessary, we can simply use the byte offset into the GDT as the selector.
 
 This is also the first mention of the LDT (local descriptor table). The LDT uses the same structure as the GDT, but is loaded into a separate register. The idea being that the GDT would hold system descriptors, and the LDT would hold process-specific descriptors. This tied in with the hardware task switching that existed in protected mode. The LDT still exists in long mode, but should be considered deprecated by paging.
 
@@ -92,7 +92,7 @@ When a descriptor is loaded into the appropriate segment register, it creates a
 
 The idea is to place code in one region of memory, and then create a descriptor with a base and limit that only expose that region of memory to the cpu. Any attempts to fetch instructions from outside that region will result in a #GP fault being triggered, and the kernel will intervene.
 
-Accessing memory inside a segment is done relative to its base. Lets say we have a segment with a base of `0x1000`,
+Accessing memory inside a segment is done relative to its base. Let's say we have a segment with a base of `0x1000`,
 and some data in memory at address `0x1100`.
 The data would be accessed at address `0x100` (assuming the segment is the active DS), as addressed are translated as `segment_base + offset`. In this case the segment base is `0x1000`, and the offset is `0x100`.
 
@@ -115,7 +115,7 @@ mov $0x10, %ax
 mov %ax, %ss
 ```
 
-Changing CS (code segment) is a little trickier, as it can't be written to directly, instead it requires a far jump. Or in this case, a far return which performs the same job, it just get its values from the stack instead of from immediate operands.
+Changing CS (code segment) is a little trickier, as it can't be written to directly, instead it requires a far jump. Or in this case, a far return which performs the same job, it just gets its values from the stack instead of from immediate operands.
 
 ```x86asm
 reload_cs:
@@ -163,14 +163,14 @@ These are further distinguished with the `type` field, as outlined below.
 | 55              | 1                | Granularity: if set, limit is interpreted as 0x1000 sized chunks, otherwise as bytes |
 | 56              | 8                | Base address bits 31: 4                               |
 
-For system-type descriptors, it's best to consult the manual, the Intel SDM volume 3A chapter 3.5 has the relevent details.
+For system-type descriptors, it's best to consult the manual, the Intel SDM volume 3A chapter 3.5 has the relevant details.
 
 The _Selector Type_ is a multibit field, for non-system descriptor types, the MSB (bit 3) is set for code descriptors, and cleared for data descriptors.
 The LSB (bit 0) is a flag for the cpu to communicate to the OS that the descriptor has been accessed in someway, but this feature is mostly abandoned, and should not be used.
 
 For a data selector, the remaining two bits are: expand-down (bit 2) - causes the limit to grow downwards, instead of up. Useful for stack selectors. Write-allow (bit 1), allows writing to this region of memory. Region is read-only if cleared.
 
-For a code selector, the remaining bits are: Conforming (bit 2) - a tricky subject to explain. Allow user code to run with kernel selectors under certain circumstances, best left cleared. Read-allow (bit 1), allows for read-only access to code for accessing constants stored near instructions. Otherwise code cannot be read as data, only for instruction fetches.
+For a code selector, the remaining bits are: Conforming (bit 2) - a tricky subject to explain. Allow user code to run with kernel selectors under certain circumstances, best left cleared. Read-allow (bit 1), allows for read-only access to code for accessing constants stored near instructions. Otherwise, code cannot be read as data, only for instruction fetches.
 
 ## Using the GDT
 
@@ -205,7 +205,7 @@ For the type field we used the magic value `0b1011`. Bits 0/1/2 are the accessed
 
 All the flags we've been setting are actually in the *upper* 32-bits of the descriptor, so we left shift by 32 bits before we place the descriptor in the GDT. The lower 32-bits of the descriptor are the limit and part of the offset fields, which are ignored in long mode.
 
-For the kernel data selector we'd doing something similar:
+For the kernel data selector we'd do something similar:
 
 ```c
 uint64_t kernel_data = 0;