Test markdown detection (#96)

* Add markdown detection as language * Update FUNDING.yml * Update README.md Update some parts of the readme, removing text staitng that was a work in progress. * Typo fixes * Fix typo in boot protocols chapter * Minor fixes on boot protocl chapter * Add detail for gdb * Fix error in cross comiler character * Update updates
dreamportdev · Sep 8, 2024 · 8969dac · 8969dac
1 parent 7b4257d
commit 8969dac
Show file tree

Hide file tree

Showing 10 changed files with 22 additions and 19 deletions.
diff --git a/.gitattributes b/.gitattributes
@@ -0,0 +1,2 @@
+*.md linguist-detectable=true
+*.md linguist-documentation=false
diff --git a/.github/FUNDING.yml b/.github/FUNDING.yml
@@ -3,10 +3,10 @@
 github: dreamos82
 patreon: inuyasha82
 open_collective: # Replace with a single Open Collective username
-ko_fi: # Replace with a single Ko-fi username
+ko_fi: dreamos82
 tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
 community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
 liberapay: # Replace with a single Liberapay username
 issuehunt: # Replace with a single IssueHunt username
 otechie: # Replace with a single Otechie username
-custom: https://www.buymeacoffee.com/dreamos82
+custom:
diff --git a/01_Build_Process/02_Boot_Protocols.md b/01_Build_Process/02_Boot_Protocols.md
@@ -8,7 +8,7 @@ This chapter covers 2 protocols _Sultiboot 2_ and _Stivale 2_:
 
 * _Stivale 2_ (also superceding stivale 1) is the native protocol of the limine bootloader. Limine and stivale were designed many years after multiboot 2 as an attempt to make hobbyist OS development easier. _Stivale 2_ is a more complex spec to read through, but it leaves the machine in a more known state prior to handing off to the kernel.
 
-Recently limine has added a new protocol (the limine boot protocol) which is not covered here. It's based on stivale2, with mainly architectural architectural changes, but similar concepts behind it. If familiar with the concepts of stivale 2, the limine protocol is easy enough to understand.
+Recently limine has added a new protocol (the limine boot protocol) which is not covered here. It's based on stivale2, with mainly architectural changes, but similar concepts behind it. If familiar with the concepts of stivale 2, the limine protocol is easy enough to understand.
 
 All the referenced specifications and documents are provided as links at the start of this chapter/in the readme.
 
@@ -215,9 +215,9 @@ Stivale 2 has a number of major differences to multiboot 2 though:
 
 - The kernel starts in 64-bit long mode, by default. No need for a protected mode stub to setup up some initial paging.
 - The kernel starts with the first 4GB of memory and any usable regions of memory identity mapped.
-- Stivale 2 also sets up a 'higher half direct map', or hhdm. This is the same identity map as the lower half, but it starts as the hhdm_offset returned in a struct tag when the kernel runs. The idea is that as long we ensure all the pointers are in the higher half, we can zero the bottom half of the page tables and easily be ready for userspace programs. No need to move code/data around.
+- Stivale 2 also sets up a _higher half direct map_, or _hhdm_. This is the same identity map as the lower half, but it starts at the `hhdm_offset` returned in a struct tag when the kernel runs. The idea is that as long we ensure all the pointers are in the higher half, we can zero the bottom half of the page tables and easily be ready for userspace programs. No need to move code/data around.
 - A well-defined GDT is provided.
-- Unlike mb2, a distinction is made between usable memory and the memory used by the bootloader, kernel/modules, and framebuffer. These are separate types in the memory, and don't intersect. Meaning usable memory regions can be used immediately.
+- Unlike _mb2_, a distinction is made between usable memory and the memory used by the bootloader, kernel/modules, and framebuffer. These are separate types in the memory, and don't intersect. Meaning usable memory regions can be used immediately.
 
 To get the next tag in the chain, it's as simple as:
 

diff --git a/02_Architecture/06_ACPITables.md b/02_Architecture/06_ACPITables.md
@@ -8,7 +8,7 @@ We need to access the ACPI Tables in order to read the IO-APIC information, used
 
 Most of the information is organized and accessible through different data structures, but since the ACPI spec is quite big, and covers so many different components, we focus only on what we need to get the information about the APIC.
 
-Before proceeding, let's keep in mind that all address described below are physical, so if we have enabled paging, we need to ensure they are properly mapped in the virtual memory space.
+Before proceeding, let's keep in mind that all addresses described below are physical, so if we we have enabled paging, we need to ensure they are properly mapped in the virtual memory space.
 
 ### RSDP
 
@@ -82,7 +82,7 @@ bool validate_RSDP(char *byte_array, size_t size) {
 }
 ```
 
-Having last byte means that `result mod 0x100` is 0. Now there are two ways to test it:
+Having last byte equals `0`, means that `result mod 0x100` is 0. Now there are two ways to test it:
 
 * Using the `mod` instruction, and check the result, if is 0 the structure is valid, otherwise it should be ignored.
 * Just checking the last byte of the result it can be achieved in several ways: for example is possible  cast the result to `uint_8` if the content after casting is 0 the struct is valid, or use bitwise AND with `0xFF` value (`0xFF` is equivalent to the `0b11111111` byte) `sum & 0xFF`, if it is 0 the struct is valid otherwise it has to be ignored.

diff --git a/02_Architecture/07_APIC.md b/02_Architecture/07_APIC.md
@@ -17,7 +17,7 @@ Both types of APIC are accessed by memory mapped registers, with 32-bit wide reg
 
 ## Local APIC
 
-When a system boots up, the cpu starts in PIC8259A emulation mode for legacy reasons. This simply means that instead of having the LAPIC and I/O APIC up and running, we have them working to emulate the old interrupt controller, so before we can use them properly we should to disable the PIC8259 emulation.
+When a system boots up, the cpu starts in PIC8259A emulation mode for legacy reasons. This simply means that instead of having the LAPIC and I/O APIC up and running, we have them working to emulate the old interrupt controller, so before we can use them properly we should disable the PIC8259 emulation.
 
 ### Disabling The PIC8259
 

diff --git a/08_VirtualFileSystem/02_VirtualFileSystem.md b/08_VirtualFileSystem/02_VirtualFileSystem.md
@@ -24,8 +24,8 @@ It shows a portion of a unix directory tree (starting from root), the gray circl
 
 So for example:
 
-* /home/userA point to a folder into the file system that is loaded at the "/" folder (we say that it's *mounted*)
-* /mnt/ext_device instead points to a file that is mounted within the /mnt folder
+* /home/user1 point to a folder into the file system that is loaded at the "/" folder (we say that it's *mounted*)
+* /mnt/ext_device/A instead points to a file that is mounted within the /mnt folder
 
 When a filesystem is *mounted* in a folder it means that the folder is no longer a container of other files/directories for the same filesystem but is referring to another one somewhere else (it can be a network drive, external device, an image file, etc.) and the folder takes the name of *mountpoint*.
 

diff --git a/99_Appendices/E_Cross_Compilers.md b/99_Appendices/E_Cross_Compilers.md
@@ -138,7 +138,7 @@ As usual let's create a new folder called `build_qemu` and move into it. The con
 ```
 where:
 
-* `--target-list=riscv64-softmmu,x86_64`: is a comma separated list of platforms we want to support.
+* `--target-list=riscv64-softmmu,x86_64-softmmu`: is a comma separated list of platforms we want to support.
 * `--enable-tools`: will build support utilities that comes with qemu
 * `--enable-gtk`: it will enable the gtk+ interface
 * `--enable-vhost-net` : it will enable the vhost-net kernel acceleration support
@@ -167,6 +167,8 @@ The last two options enable compiling the text-user-interface (`--enable-tui`) a
 
 The `--target=` flag is special here in that it can also take an option `all` which builds gdb with support for every single architecture it can support. If we're going to develop on one machine but test on multiple architectures (via qemu or real hardware) this is nice. It allows a single instance of gdb to debug multiple architectures without needing different versions of gdb. Often this is how the 'gdb-multiarch' package is created for distros that have it.
 
+The `--host=` flags specify the host system running gdb, in the example above an `x86_64-linux-gnu` system, this should be changed depedning on the system used.
+
 After running the configure script, we can build and install our custom gdb like so:
 
 ```bash

diff --git a/99_Appendices/J_Updates.md b/99_Appendices/J_Updates.md
@@ -49,7 +49,7 @@ Fourth book release
 
 ### Revision 4
 
-Release date: TBD
+Release date: Sept 2024
 Fifth book release
 
 * Typo fixes

diff --git a/99_Appendices/README.md b/99_Appendices/README.md
@@ -5,7 +5,8 @@
 - [Appendix C: C Language Extras](C_Language_Info.md)
 - [Appendix D: Using NASM](D_Nasm.md)
 - [Appendix E: Cross Compilers](E_Cross_Compilers.md)
-- [Appendix F: Debugging](E_Debugging.md)
-- [Appendix G: Memory Protection](F_Memory_Protection.md)
-- [Appendix H: Useful Resources](G_Useful_Resources.md)
-- [Appendix I: Acknowledgments](H_Acknowledgments.md)
+- [Appendix F: Debugging](F_Debugging.md)
+- [Appendix G: Memory Protection](G_Memory_Protection.md)
+- [Appendix H: Useful Resources](H_Useful_Resources.md)
+- [Appendix I: Acknowledgments](I_Acknowledgments.md)
+- [Appendix J: Updates](J_Updates.md)
diff --git a/README.md b/README.md
@@ -6,9 +6,7 @@
 </span>
 ![](https://tokei.rs/b1/github/dreamos82/osdev-notes)
 
-A collection of notes, organised as a book, intended to guide a reader through the steps of building an operating system kernel from scratch. Written while writing (and re-writing) our own kernels, each chapter covers a step from selecting a bootloader to running a loaded ELF in userspace.
-
-Currently these notes are a work in progress, but many chapters are functionally complete and available to read below. We'll keep updating old chapters and adding new ones over time so be sure to check back occasionally.
+A book, originated as a collection of notes, intended to guide a reader through the steps of building an operating system kernel from scratch. Written while writing (and re-writing) our own kernels, each chapter covers a step of the process from selecting a bootloader to running a loaded ELF in userspace.
 
 We hope you enjoy, and find something interesting here!