Minor updates on md syntax and few typo fix

Author: dreamos82

04_Memory_Management/02_Physical_Memory.md

@@ -14,9 +14,9 @@ In this chapter we will explain the bitmap method, because is probably the simpl
 
 ## The Bitmap
 
-Now let's start with a simple example, imagine that we have a very tiny amount of ram like 256kb of ram, and we want to use 4kb pages, and assume that we have the kernel that takes the first 3 pages. As said above using the bitmap method assign 1 bit to every page, this means that every bytes can keep track of $8*4k=32kb$ of memory, if the page is taken the bit is set to 1, if is free the bit is clear (=0)
+Now let's start with a simple example, imagine that we have a very tiny amount of memory like `256kb` of ram, and we want to use `4kb` pages, and assume that we have the kernel that takes the first 3 pages. As said above using the bitmap method it assign 1 bit to every page, this means that every bytes can keep track of $8*4k=32kb$ of memory. If the page is taken the bit is set to 1, if is free the bit is clear (=0)
 
-This means that a single *unsigned char* variable can hold the status of 32kb of ram, to keep track of 256kb of ram we then need 8bytes (They can stay in a single `uint64_t` variable, but for this example let's stick with the char type), this means that with an array of 8 elements of *unsigned char* we can represent the whole amount of memory, so we are going to have something like this:
+This means that a single *unsigned char* variable can hold the status of `32kb` of memory, to keep track of `256kb` of ram we then need 8bytes (They can stay in a single `uint64_t` variable, but for this example let's stick with the char type), this means that with an array of 8 elements of *unsigned char* we can represent the whole amount of memory, so we are going to have something like this:
 
 
 |           | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |

06_Userspace/04_System_Calls.md

@@ -3,7 +3,7 @@ System calls are a way for a user mode program to request something from the ker
 
 On `x86_64` there are a few ways to perform a system call. The first is to dedicate an interrupt vector to be used for software interrupts. This is the most common, and straightforward way. The other main way is to use the dedicated instructions (`sysenter` and friends), however these are rather niche and have some issues of their own. This is discussed below.
 
-There are other obscure ways to perform syscalls. For example, executing a bad instruction will cause the cpu to trigger a #UD exception. This transfers control to supervisor code, and could be used as an entry to a system call. While not recommended for beginners, there was one hobby OS kernel that used this method.
+There are other obscure ways to perform syscalls. For example, executing a bad instruction will cause the cpu to trigger a `#UD` exception. This transfers control to supervisor code, and could be used as an entry to a system call. While not recommended for beginners, there was one hobby OS kernel that used this method.
 
 ## The System Call ABI
 A stable ABI is always a good thing, but especially in the case of system calls. If we start to write user code that uses your system calls, and then the ABI changes later, all of the previous code will break. Therefore it's recommended to take some time to design the core of the ABI before implementing it.

08_VirtualFileSystem/02_VirtualFileSystem.md

@@ -199,7 +199,7 @@ Implementing the function is left as exercise, below we just declare the header
 mountpoint_t get_mountpoint(char *path);
 ```
 
-If the above function fail it should return  NULL to let the caller know that something didn't work (even if it should always return at least the root "/" item in a single root implementation).
+If the above function fail it should return  `NULL` to let the caller know that something didn't work (even if it should always return at least the root `/` item in a single root implementation).
 
 #### Absolute vs Relative Path
 
@@ -305,7 +305,7 @@ struct fs_operations_t {
 typedef struct fs_operations_t fs_operations_t;
 ```
 
-The basic idea is that once mountpoint_id has been found, the vfs will use the mountpoint item to call the fs driver implementation of the open function, remember that when calling the driver function, it cares only about the relative path with mountpoint folder stripped, if the whole path is passed, we will most likely get an error. Since the fs root will start from within the mountpoint folder we need to get the relative path, we will use the `get_rel_path` function defined earlier in this chapter, and the pseudocode for the open function should look similar to the following:
+The basic idea is that once `mountpoint_id` has been found, the vfs will use the mountpoint item to call the fs driver implementation of the open function, remember that when calling the driver function, it cares only about the relative path with mountpoint folder stripped, if the whole path is passed, we will most likely get an error. Since the fs root will start from within the mountpoint folder we need to get the relative path, we will use the `get_rel_path` function defined earlier in this chapter, and the pseudocode for the open function should look similar to the following:
 
 
 ```c