Docs: fix multiple typos in various files

docs/modules/module-06.md

@@ -38,14 +38,14 @@ Set the TICK field of the process table entry of the selected process to 0.
 /* When the process goes to swap, TICK starts again */
 
 Call the <b>release_page()</b> function in the <a href="../../modules/module-02/">Memory Manager</a> module to deallocate the valid code pages of the process.
-Invalidate the <a href="../../os-design/process-table/#per-process-page-table">Page table</a> entry correpsonding to the code pages.
+Invalidate the <a href="../../os-design/process-table/#per-process-page-table">Page table</a> entry corresponding to the code pages.
 
 <b>For</b> each heap page that is not shared and is valid {	/* Shared heap pages are not swapped out. */
 	Get a free swap block by calling the <b>get_swap_block()</b> function in the <a href="../../modules/module-02/">Memory Manager</a> module.
 	Store the disk block number in the <a href="../../os-design/process-table/#per-process-disk-map-table">Disk Map Table</a> entry of the process curresponding to the heap page.
 	Use the <b>disk_store()</b> function in the <a href="../../modules/module-04/">Device Manager</a> module to write the heap page to the block found above
 	Call the <b>release_page()</b> function in the <a href="../../modules/module-02/">Memory Manager</a> module to deallocate the page.
-	Invalidate the Page table entry correpsonding to the page.
+	Invalidate the Page table entry corresponding to the page.
 }
 
 Get two free swap block by calling the <b>get_swap_block()</b> function in the <a href="../../modules/module-02/">Memory Manager</a> module.
@@ -56,7 +56,7 @@ Call the <b>release_page()</b> function in the <a href="../../modules/module-02/
 
 Update the Disk Map Table entry of the process to store the disk block numbers of the stack.
 
-Invalidate the Page table entries correpsonding to the two stack pages.
+Invalidate the Page table entries corresponding to the two stack pages.
 
 Set the SWAP_FLAG field in the process table entry of the process to 1.
 
@@ -99,15 +99,15 @@ Set the TICK field of the process table entry of the selected process to 0.
 	Get the disk block number in the <a href="../../os-design/process-table/#per-process-disk-map-table">Disk Map Table</a> entry of the process corresponding to the heap page.
 	Use the <b>disk_load()</b> function in the <a href="../../modules/module-04/">Device Manager</a> module to copy the heap page found above to the memory.
 	Free the swap block by calling the <b>release_block()</b> function in the <a href="../../modules/module-02/">Memory Manager</a> module.
-	Set the Page table entry correpsonding to the page. Reference bit is set to 0, valid bit and write bit are set to 1.
+	Set the Page table entry corresponding to the page. Reference bit is set to 0, valid bit and write bit are set to 1.
     Invalidate the Disk Map Table entry corresponding to the heap page.
 }
 
 Get two free memory pages by calling the <b>get_free_page()</b> function in the <a href="../../modules/module-02/">Memory Manager</a> module.
 
 Use the <b>disk_load()</b> function in the <a href="../../modules/module-04/">Device Manager</a> module to load the two stack pages to the memory allocated above.
 
-Set the Page table entries correpsonding to the two stack pages. The pages are valid, unreferenced and writable.
+Set the Page table entries corresponding to the two stack pages. The pages are valid, unreferenced and writable.
 
 Call the <b>release_block()</b> function in the <a href="../../modules/module-02/">Memory Manager</a> module to deallocate the two swap blocks.
 
@@ -134,4 +134,4 @@ Called by timer interrupt.
 
 
 
-
+

docs/os-design/close.md

@@ -49,7 +49,7 @@ If the Resource identifier field of the <a href="../../os-design/process-table/#
 
 Get the index of the <a href="../../os-design/mem-ds/#open-file-table" target="_blank">Open File Table</a> entry from Per-Process Resource Table entry.
 
-Call the <b>close()</b> function in the <a href="../../modules/module-03/">File Manager module</a> with the Open File Table index as arguement.
+Call the <b>close()</b> function in the <a href="../../modules/module-03/">File Manager module</a> with the Open File Table index as argument.
 
 Invalidate the <a href="../../os-design/process-table/#per-process-resource-table" target="_blank">Per-Process Resource Table</a> entry.
 

docs/os-design/exec.md

@@ -57,7 +57,7 @@ to invoke the memory manager module for allocating a fresh user area page (why?)
 
 Set SP to User Area Page Number * 512 - 1 /* Start fresh in the new kernel stack */
 
-Initilize the <a href="../../os-design/process-table/#per-process-resource-table">Per-process Resource Table</a> by setting all entries to -1.	
+Initialize the <a href="../../os-design/process-table/#per-process-resource-table">Per-process Resource Table</a> by setting all entries to -1.	
 
 In the <a href="../../os-design/process-table/">Process Table</a> entry of the current process, set the Inode Index field to the 
 index of Inode Table entry for the file and set the state as RUNNING.

docs/os-design/fork.md

@@ -72,7 +72,7 @@ to the new UA Page, MODE, TICK and Kernel Stack Pointer to 0.
 
 /* Kernel Context of the child process is empty */
 
-/* PID, PTBR, PTLR fields of the child's process table is initilized by the get_pcb_entry function.*/ 
+/* PID, PTBR, PTLR fields of the child's process table is initialized by the get_pcb_entry function.*/ 
 
 Copy the <a href="../../os-design/process-table/#per-process-resource-table">per-process resource table</a> and <a href="../../os-design/process-table/#per-process-disk-map-table">per-process disk map table</a>.
 For every open file of the parent, increment the Open Instance Count in the <a href="../../os-design/mem-ds/#open-file-table" target="_blank">Open File Table</a>.
@@ -104,4 +104,4 @@ Restore SP to User SP and return to the parent process.
 </code></pre>
 
 !!! note
-    At each point of return from the system call, remember to reset the MODE FLAG and switch back to the user stack.
+    At each point of return from the system call, remember to reset the MODE FLAG and switch back to the user stack.

docs/os-design/multiusersyscalls.md

@@ -249,7 +249,7 @@ This system call is used to login a new user. It can be executed only from the l
 	Get the <a href="../../os-design/disk-ds/#user-table">User Table</a> entry curresponding to the username.
 	If an entry does not exist, return -1.
 
-	Use the <a href="../../support-tools/spl/">ecrypt statement</a> to encrypt the password supplied as input.
+	Use the <a href="../../support-tools/spl/">encrypt statement</a> to encrypt the password supplied as input.
 
 	If the encypted input password does not match the ENCRYPTED PASSWORD field in the user table entry, return -1.
 

docs/os-design/term-handler.md

@@ -39,7 +39,7 @@ ireturn;
 
 
 !!! question 
-    When interrupts or system calls are invloked, the mode changes from user to kernel. Registers are backed up using the BACKUP instruction in the case of interrupts and not in the case of system calls. Why?
+    When interrupts or system calls are invoked, the mode changes from user to kernel. Registers are backed up using the BACKUP instruction in the case of interrupts and not in the case of system calls. Why?
 
 
 

docs/os-spec/expos-abstractions.md

@@ -17,7 +17,7 @@ eXpOS provides the following fundamental abstractions to an application program:
 
 ### The eXpFS logical file system
 
-The eXpOS kernal provides a hardware independent logical file system model (called the **experimental file system or eXpFS**) for application programs. The application program views files as being organized and stored in the eXpFS logical file system. Application programs are not permitted to access files directly. Instead, they must invoke the appropriate **file system call** for creating, modifying or accessing files. The OS routine implementing each system call internally translates the request into disk block operations, hiding the hardware details from the application program.
+The eXpOS kernel provides a hardware independent logical file system model (called the **experimental file system or eXpFS**) for application programs. The application program views files as being organized and stored in the eXpFS logical file system. Application programs are not permitted to access files directly. Instead, they must invoke the appropriate **file system call** for creating, modifying or accessing files. The OS routine implementing each system call internally translates the request into disk block operations, hiding the hardware details from the application program.
 
 
 eXpFS support three kinds of files - **data files, program files**  (executable files) and a special file called the **root file.**  The root file is a meta-data file that contains the list of all files in the file system. A data file consists of a sequence of words. A program contains a header, a sequence of machine instructions called text and static data, if any. 
@@ -38,7 +38,7 @@ A detailed discussion of the file system structure, file system calls and XEXE f
 
 ### The eXpOS process Abstraction
 
-It was noted earlier that at the end of bootstrap, eXpOS loads into memory a program stored in a pre-determined part of the disk and creates the first process called the INIT process. Once a process is created, it can spawn new processes using the **fork**  system call. When a process spawns a new process, the former is called the **parent process** and the later is called the **child process**. A process can decide to terminate itself using the **exit** system call. 
+It was noted earlier that at the end of bootstrap, eXpOS loads into memory a program stored in a pre-determined part of the disk and creates the first process called the INIT process. Once a process is created, it can spawn new processes using the **fork**  system call. When a process spawns a new process, the former is called the **parent process** and the latter is called the **child process**. A process can decide to terminate itself using the **exit** system call. 
 
 
  * In the extended eXpOS specification, the INIT process is called the LOGIN process and is executed directly by the kernel. This process invokes the login system call to log a user in. Once a user is logged in, the shell process is created for the user and the original login process waits for the termination of the user shell, to log in the next user. 
@@ -92,10 +92,10 @@ The file sharing semantics between users in Multiuser extension to eXpOS is desc
 
 ### System Calls
 
-The eXpOS system calls are software interrupt routines of the eXpOS kernal which are loaded into the memory when the OS is bootstrapped. These routines define the services provided by the OS to application programs. These services include accessing files and semaphores, creating new processes , sending a signal to another process etc. 
+The eXpOS system calls are software interrupt routines of the eXpOS kernel which are loaded into the memory when the OS is bootstrapped. These routines define the services provided by the OS to application programs. These services include accessing files and semaphores, creating new processes , sending a signal to another process etc. 
 
 
-Application programs are not permitted to directly access files/semaphores or create new processes. Instead they must invoke the corresponding system call routines. System calls are kernal routines and operate in **privileged or system mode**. Thus when an application program invokes a system call (by invoking the corresponding software interrupt), a change of mode from unprivileged mode to privileged mode occurs. The system call code checks whether the request is valid and the process has permission to the resources/actions requested and then perform the request. Upon completion of the interrupt service routine, control is transferred back to the user process with a switch back to the unprivileged mode. 
+Application programs are not permitted to directly access files/semaphores or create new processes. Instead they must invoke the corresponding system call routines. System calls are kernel routines and operate in **privileged or system mode**. Thus when an application program invokes a system call (by invoking the corresponding software interrupt), a change of mode from unprivileged mode to privileged mode occurs. The system call code checks whether the request is valid and the process has permission to the resources/actions requested and then perform the request. Upon completion of the interrupt service routine, control is transferred back to the user process with a switch back to the unprivileged mode. 
 
 
 eXpOS system calls can be classified as file system calls, process system calls and system calls for access control and synchronization. The following table lists the system calls. A detailed specification can be found [here](systemcallinterface.md).

docs/roadmap/stage-16.md

@@ -27,7 +27,7 @@ infer that the execution of the IN instruction is complete.
 
 As noted above, the IN instruction is typically executed from the Terminal Read function.
 Since it is not useful for the process that invoked the Terminal Read function to continue
-execution till data arrives in P0, **a process executing the IN instruction will sets its state to WAIT_TERMINAL and invoke the scheduler**. The process must resume execution only after the XSM machine sends an interrupt upon data arrival.
+execution till data arrives in P0, **a process executing the IN instruction will set its state to WAIT_TERMINAL and invoke the scheduler**. The process must resume execution only after the XSM machine sends an interrupt upon data arrival.
 
 
 When the console interrupt occurs, the machine interrupts the current process (note that some

docs/roadmap/stage-17.md

@@ -237,7 +237,7 @@ memory page and updates the WAIT_MEM_COUNT and MEM_FREE_COUNT in the system stat
     Since the page storing the kernel context has been de-allocated, before making any function call, a stack page has to be allocated to store parameters, return address etc. It is unsafe to invoke the Get Free Page function of the memory manager module before allocating a stack page (why?).
 
 ??? question "Q2 Why should the OS set the WRITE PERMISSION BIT for library and code pages in each page table entry to 0, denying permission for the process to write to these pages?"
-    ExpOS does not expect processess to modify the code page during execution. Hence,
+    ExpOS does not expect processes to modify the code page during execution. Hence,
     during a fork() system call (to be seen in later stages), the code pages are shared
     between several processes. Similarly, the library pages are shared by all processes. If
     a process is allowed to write into a code/library page, the shared program/library will

docs/roadmap/stage-18.md

@@ -35,7 +35,7 @@ acquired the disk, the PID of the process is also stored in the disk status tabl
 constant [DISK_STATUS_TABLE](../support-tools/constants.md)gives the starting address of the Disk Status Table in the[XSM memory](../os-implementation.md).
 
 After the current process has acquired the disk for loading, it initializes the Disk Status
-Table according to the operation to be perfromed (read/write). The process then issues the
+Table according to the operation to be performed (read/write). The process then issues the
 <i>load</i> statement to initiate the loading of the disk block to the memory page. As mentioned earlier,
 the XSM machine does not wait for the transfer to complete. It continues with the execution of
 the next instruction. However, virtually in any situation in eXpOS, the process has to wait
@@ -155,4 +155,4 @@ Compile and load the modified and newly written files into the disk using XFS-in
 
 
 !!! assignment "Assignment 1"
-    Use the[XSM debugger](../support-tools/xsm-simulator.md)to print out the contents of the Disk Status Table after entry and before return from the disk interrupt handler.
+    Use the[XSM debugger](../support-tools/xsm-simulator.md)to print out the contents of the Disk Status Table after entry and before return from the disk interrupt handler.

docs/roadmap/stage-19.md

@@ -52,7 +52,7 @@ application, but because the OS had not loaded the page and set the page tables.
     present strategy of "lazy allocation" to be described now. The strategy followed in this
     stage is to start executing a process with just one page of code and two pages of stack
     allocated initially. When the process, during execution, tries to access a page that was not
-    loaded, an exception is generated and the execption handler will allocate the required page.
+    loaded, an exception is generated and the exception handler will allocate the required page.
     If the required page is a code page, the page will be transferred from the disk to the
     allocated memory. Since pages are allocated only on demand, memory utilization is better (on
     the average) with this approach.
@@ -247,4 +247,4 @@ Compile and load the modified and newly written files into the disk using the XF
     Write an ExpL program to implement a linked list. Your program should first read an integer N, then read N intergers from console and store them in the linked list and print the linked list to the console. Run this program using shell version-I of stage 17.
 
 !!! assignment "Assignment 2"
-    Use the [XSM debugger](../support-tools/xsm-simulator.md) to dump the contents of the Exception Flag registers upon entry into the Exception Handler. Also, print out the contents of the Disk Map Table and the Page Table after the Get Code Page function (inside the Memory Manager module).
+    Use the [XSM debugger](../support-tools/xsm-simulator.md) to dump the contents of the Exception Flag registers upon entry into the Exception Handler. Also, print out the contents of the Disk Map Table and the Page Table after the Get Code Page function (inside the Memory Manager module).