Fix internal links

blog/content/second-edition/posts/06-double-faults/index.md

@@ -21,7 +21,7 @@ This blog is openly developed on [GitHub]. If you have any problems or questions
 ## What is a Double Fault?
 In simplified terms, a double fault is a special exception that occurs when the CPU fails to invoke an exception handler. For example, it occurs when a page fault is triggered but there is no page fault handler registered in the [Interrupt Descriptor Table][IDT] (IDT). So it's kind of similar to catch-all blocks in programming languages with exceptions, e.g. `catch(...)` in C++ or `catch(Exception e)` in Java or C#.
 
-[IDT]: ./second-edition/posts/06-cpu-exceptions/index.md#the-interrupt-descriptor-table
+[IDT]: ./second-edition/posts/05-cpu-exceptions/index.md#the-interrupt-descriptor-table
 
 A double fault behaves like a normal exception. It has the vector number `8` and we can define a normal handler function for it in the IDT. It is really important to provide a double fault handler, because if a double fault is unhandled a fatal _triple fault_ occurs. Triple faults can't be caught and most hardware reacts with a system reset.
 
@@ -193,7 +193,7 @@ struct InterruptStackTable {
 
 For each exception handler, we can choose a stack from the IST through the `options` field in the corresponding [IDT entry]. For example, we could use the first stack in the IST for our double fault handler. Then the CPU would automatically switch to this stack whenever a double fault occurs. This switch would happen before anything is pushed, so it would prevent the triple fault.
 
-[IDT entry]: ./second-edition/posts/06-cpu-exceptions/index.md#the-interrupt-descriptor-table
+[IDT entry]: ./second-edition/posts/05-cpu-exceptions/index.md#the-interrupt-descriptor-table
 
 ### The IST and TSS
 The Interrupt Stack Table (IST) is part of an old legacy structure called _[Task State Segment]_ \(TSS). The TSS used to hold various information (e.g. processor register state) about a task in 32-bit mode and was for example used for [hardware context switching]. However, hardware context switching is no longer supported in 64-bit mode and the format of the TSS changed completely.

blog/content/second-edition/posts/08-paging-introduction/index.md

@@ -257,7 +257,7 @@ Paging makes our kernel already relatively safe, since every memory access that
 
 Let's try to cause a page fault by accessing some memory outside of our kernel. First, we create a page fault handler and register it in our IDT, so that we see a page fault exception instead of a generic [double fault] :
 
-[double fault]: ./second-edition/posts/07-double-faults/index.md
+[double fault]: ./second-edition/posts/06-double-faults/index.md
 
 ```rust
 // in src/interrupts.rs
@@ -296,7 +296,7 @@ The [`CR2`] register is automatically set by the CPU on a page fault and contain
 [`Cr2::read`]: https://docs.rs/x86_64/0.5.2/x86_64/registers/control/struct.Cr2.html#method.read
 [`PageFaultErrorCode`]: https://docs.rs/x86_64/0.5.2/x86_64/structures/idt/struct.PageFaultErrorCode.html
 [LLVM bug]: https://github.com/rust-lang/rust/issues/57270
-[`hlt_loop`]: ./second-edition/posts/08-hardware-interrupts/index.md#the
+[`hlt_loop`]: ./second-edition/posts/07-hardware-interrupts/index.md#the
 
 Now we can try to access some memory outside our kernel:
 

blog/content/second-edition/posts/09-paging-implementation/index.md

@@ -37,11 +37,11 @@ I hope that you enjoy this new post!
 
 The [previous post] gave an introduction to the concept of paging. It motivated paging by comparing it with segmentation, explained how paging and page tables work, and then introduced the 4-level page table design of `x86_64`. We found out that the bootloader already set up a page table hierarchy for our kernel, which means that our kernel already runs on virtual addresses. This improves safety since illegal memory accesses cause page fault exceptions instead of modifying arbitrary physical memory.
 
-[previous post]: ./second-edition/posts/09-paging-introduction/index.md
+[previous post]: ./second-edition/posts/08-paging-introduction/index.md
 
 The post ended with the problem that we [can't access the page tables from our kernel][end of previous post] because they are stored in physical memory and our kernel already runs on virtual addresses. This post continues at this point and explores different approaches of making the page table frames accessible to our kernel. We will discuss the advantages and drawbacks of each approach and then decide for an approach for our kernel.
 
-[end of previous post]: ./second-edition/posts/09-paging-introduction/index.md#accessing-the-page-tables
+[end of previous post]: ./second-edition/posts/08-paging-introduction/index.md#accessing-the-page-tables
 
 To implement the approach, we will need support from the bootloader, so we'll configure it first. Afterward, we will implement a function that traverses the page table hierarchy in order to translate virtual to physical addresses. Finally, we learn how to create new mappings in the page tables and how to find unused memory frames for creating new page tables.
 
@@ -83,7 +83,7 @@ In this example, we see various identity-mapped page table frames. This way the
 However, it clutters the virtual address space and makes it more difficult to find continuous memory regions of larger sizes. For example, imagine that we want to create a virtual memory region of size 1000 KiB in the above graphic, e.g. for [memory-mapping a file]. We can't start the region at `28 KiB` because it would collide with the already mapped page at `1004 MiB`. So we have to look further until we find a large enough unmapped area, for example at `1008 KiB`. This is a similar fragmentation problem as with [segmentation].
 
 [memory-mapping a file]: https://en.wikipedia.org/wiki/Memory-mapped_file
-[segmentation]: ./second-edition/posts/09-paging-introduction/index.md#fragmentation
+[segmentation]: ./second-edition/posts/08-paging-introduction/index.md#fragmentation
 
 Equally, it makes it much more difficult to create new page tables, because we need to find physical frames whose corresponding pages aren't already in use. For example, let's assume that we reserved the _virtual_ 1000 KiB memory region starting at `1008 KiB` for our memory-mapped file. Now we can't use any frame with a _physical_ address between `1000 KiB` and `2008 KiB` anymore, because we can't identity map it.
 
@@ -210,7 +210,7 @@ Whereas `AAA` is the level 4 index, `BBB` the level 3 index, `CCC` the level 2 i
 
 `SSSSSS` are sign extension bits, which means that they are all copies of bit 47. This is a special requirement for valid addresses on the x86_64 architecture. We explained it in the [previous post][sign extension].
 
-[sign extension]: ./second-edition/posts/09-paging-introduction/index.md#paging-on-x86
+[sign extension]: ./second-edition/posts/08-paging-introduction/index.md#paging-on-x86
 
 We use [octal] numbers for representing the addresses since each octal character represents three bits, which allows us to clearly separate the 9-bit indexes of the different page table levels. This isn't possible with the hexadecimal system where each character represents four bits.
 
@@ -377,7 +377,7 @@ For the module we create an empty `src/memory.rs` file.
 
 At the [end of the previous post], we tried to take a look at the page tables our kernel runs on, but failed since we couldn't access the physical frame that the `CR3` register points to. We're now able to continue from there by creating an `active_level_4_table` function that returns a reference to the active level 4 page table:
 
-[end of the previous post]: ./second-edition/posts/09-paging-introduction/index.md#accessing-the-page-tables
+[end of the previous post]: ./second-edition/posts/08-paging-introduction/index.md#accessing-the-page-tables
 
 ```rust
 // in src/memory.rs
@@ -732,7 +732,7 @@ In addition to the `page` that should be mapped, the function expects a `mapper`
 
 For the mapping, we set the `PRESENT` flag because it is required for all valid entries and the `WRITABLE` flag to make the mapped page writable. Calling `map_to` is unsafe because it's possible to break memory safety with invalid arguments, so we need to use an `unsafe` block. For a list of all possible flags, see the [_Page Table Format_] section of the previous post.
 
-[_Page Table Format_]: ./second-edition/posts/09-paging-introduction/index.md#page-table-format
+[_Page Table Format_]: ./second-edition/posts/08-paging-introduction/index.md#page-table-format
 
 The `map_to` function can fail, so it returns a [`Result`]. Since this is just some example code that does not need to be robust, we just use [`expect`] to panic when an error occurs. On success, the function returns a [`MapperFlush`] type that provides an easy way to flush the newly mapped page from the translation lookaside buffer (TLB) with its [`flush`] method. Like `Result`, the type uses the [`#[must_use]`] attribute to emit a warning when we accidentally forget to use it.
 

blog/content/second-edition/posts/deprecated/10-advanced-paging/index.md

@@ -23,11 +23,11 @@ This blog is openly developed on [GitHub]. If you have any problems or questions
 
 In the [previous post] we learned about the principles of paging and how the 4-level page tables on x86_64 work. We also found out that the bootloader already set up a page table hierarchy for our kernel, which means that our kernel already runs on virtual addresses. This improves safety since illegal memory accesses cause page fault exceptions instead of modifying arbitrary physical memory.
 
-[previous post]: ./second-edition/posts/09-paging-introduction/index.md
+[previous post]: ./second-edition/posts/08-paging-introduction/index.md
 
 However, it also causes a problem when we try to access the page tables from our kernel because we can't directly access the physical addresses that are stored in page table entries or the `CR3` register. We experienced that problem already [at the end of the previous post] when we tried to inspect the active page tables.
 
-[at the end of the previous post]: ./second-edition/posts/09-paging-introduction/index.md#accessing-the-page-tables
+[at the end of the previous post]: ./second-edition/posts/08-paging-introduction/index.md#accessing-the-page-tables
 
 The next section discusses the problem in detail and provides different approaches to a solution. Afterward, we implement a function that traverses the page table hierarchy in order to translate virtual to physical addresses. Finally, we learn how to create new mappings in the page tables and how to find unused memory frames for creating new page tables.
 
@@ -63,7 +63,7 @@ So in order to access page table frames, we need to map some virtual pages to th
   However, it clutters the virtual address space and makes it more difficult to find continuous memory regions of larger sizes. For example, imagine that we want to create a virtual memory region of size 1000 KiB in the above graphic, e.g. for [memory-mapping a file]. We can't start the region at `28 KiB` because it would collide with the already mapped page at `1004 MiB`. So we have to look further until we find a large enough unmapped area, for example at `1008 KiB`. This is a similar fragmentation problem as with [segmentation].
 
   [memory-mapping a file]: https://en.wikipedia.org/wiki/Memory-mapped_file
-  [segmentation]: ./second-edition/posts/09-paging-introduction/index.md#fragmentation
+  [segmentation]: ./second-edition/posts/08-paging-introduction/index.md#fragmentation
 
   Equally, it makes it much more difficult to create new page tables, because we need to find physical frames whose corresponding pages aren't already in use. For example, let's assume that we reserved the _virtual_ 1000 KiB memory region starting at `1008 KiB` for our memory-mapped file. Now we can't use any frame with a _physical_ address between `1000 KiB` and `2008 KiB` anymore, because we can't identity map it.
 
@@ -156,7 +156,7 @@ Whereas `AAA` is the level 4 index, `BBB` the level 3 index, `CCC` the level 2 i
 
 `SSSSSS` are sign extension bits, which means that they are all copies of bit 47. This is a special requirement for valid addresses on the x86_64 architecture. We explained it in the [previous post][sign extension].
 
-[sign extension]: ./second-edition/posts/09-paging-introduction/index.md#paging-on-x86
+[sign extension]: ./second-edition/posts/08-paging-introduction/index.md#paging-on-x86
 
 We use [octal] numbers for representing the addresses since each octal character represents three bits, which allows us to clearly separate the 9-bit indexes of the different page table levels. This isn't possible with the hexadecimal system where each character represents four bits.