Updated Loadable Kernel Modules ELF Relocatable Objects (markdown)

Loadable-Kernel-Modules---ELF-Relocatable-Objects.md

@@ -4,13 +4,13 @@ ToaruOS uses ELF relocatable object files (the format you get with `cc -c`) to p
 
 ## Why ELF Relocatable Objects?
 
-When most people think about dynamically loading code, they turn to shared objects. But, in the context of kernel, the benefits of shared objects make very little sense, and the complexities involved in loading them only make matters worse.
-Shared objects were designed to support applications in userspace, particularly in cases where many applications need to make use of the same library.
-As such, a key feature of shared objects is their ability to loaded once in memory and "relocated" through an offset table for many different users.
-This means that shared objects make use of additional memory operations to dereference symbols, as they must look into the object table first.
-In the context of a kernel, we have no need for multiple instances of a module.
+When most people think about dynamically loading code, they turn to shared objects. But, in the context of the kernel, the benefits of shared objects make very little sense, and the complexities involved in loading them only make matters worse.
+Shared objects were designed to support applications in userspace, particularly in cases where many applications need to make use of the same library at the same time.
+As such, a key feature of shared objects is their ability to be loaded once in memory and "relocated" through an offset table for many different users, rather than directly modifying code.
+This means that shared objects make use of additional memory operations at runtime to dereference symbols, as they must look into the offset table first.
+In the context of a kernel, we have no need for multiple instances of a module - they are only loaded once for use in the kernel.
 Relocatable objects work by modifying the code itself when relocating the object, which means it can't be referenced from multiple different virtual address spaces.
-This also means that symbol references are direct, as the addresses are patched into the code instead of relying on a lookup table, which means both that there are more relocations to perform (once for every call to a symbol, rather than once for each individual symbol within the offset table), but also that speed is better at runtime.
+This also means that symbol references are direct, as the addresses are patched into the code instead of relying on a lookup table, which means both that there are more relocations to perform (once for every call to a symbol, rather than once for each individual symbol within the offset table), but also that runtime speed is improved.
 
 ## Symbol Tables