Rename first-edition subfolder to edition-1

blog/content/edition-1/_index.md

@@ -0,0 +1,5 @@
++++
+title = "First Edition"
+template = "edition-1/index.html"
+aliases = ["first-edition/index.html"]
++++

blog/content/edition-1/extra/naked-exceptions/01-catching-exceptions/index.md

@@ -4,7 +4,7 @@ weight = 1
 path = "catching-exceptions"
 aliases = ["catching-exceptions.html"]
 date  = 2016-05-28
-template = "first-edition/page.html"
+template = "edition-1/page.html"
 [extra]
 updated = "2016-06-25"
 +++
@@ -20,8 +20,8 @@ As always, the complete source code is on [GitHub]. Please file [issues] for any
 
 > **Note**: This post describes how to handle exceptions using naked functions (see [“Handling Exceptions with Naked Functions”] for an overview). Our new way of handling exceptions can be found in the [“Handling Exceptions”] post.
 
-[“Handling Exceptions with Naked Functions”]: @/first-edition/extra/naked-exceptions/_index.md
+[“Handling Exceptions with Naked Functions”]: @/edition-1/extra/naked-exceptions/_index.md
-[“Handling Exceptions”]: @/first-edition/posts/09-handling-exceptions/index.md
+[“Handling Exceptions”]: @/edition-1/posts/09-handling-exceptions/index.md
 
 ## Exceptions
 An exception signals that something is wrong with the current instruction. For example, the CPU issues an exception if the current instruction tries to divide by 0. When an exception occurs, the CPU interrupts its current work and immediately calls a specific exception handler function, depending on the exception type.

blog/content/edition-1/extra/naked-exceptions/02-better-exception-messages/index.md

@@ -4,7 +4,7 @@ weight = 2
 path = "better-exception-messages"
 aliases = ["better-exception-messages.html"]
 date  = 2016-08-03
-template = "first-edition/page.html"
+template = "edition-1/page.html"
 [extra]
 updated = "2016-11-01"
 +++
@@ -21,8 +21,8 @@ As always, the complete source code is on [GitHub]. Please file [issues] for any
 
 > **Note**: This post describes how to handle exceptions using naked functions (see [“Handling Exceptions with Naked Functions”] for an overview). Our new way of handling exceptions can be found in the [“Handling Exceptions”] post.
 
-[“Handling Exceptions with Naked Functions”]: @/first-edition/extra/naked-exceptions/_index.md
+[“Handling Exceptions with Naked Functions”]: @/edition-1/extra/naked-exceptions/_index.md
-[“Handling Exceptions”]: @/first-edition/posts/09-handling-exceptions/index.md
+[“Handling Exceptions”]: @/edition-1/posts/09-handling-exceptions/index.md
 
 ## Exceptions in Detail
 An exception signals that something is wrong with the currently-executed instruction. Whenever an exception occurs, the CPU interrupts its current work and starts an internal exception routine.

blog/content/edition-1/extra/naked-exceptions/03-returning-from-exceptions/index.md

@@ -4,7 +4,7 @@ weight = 3
 path = "returning-from-exceptions"
 aliases = ["returning-from-exceptions.html"]
 date  = 2016-09-21
-template = "first-edition/page.html"
+template = "edition-1/page.html"
 [extra]
 updated = "2016-11-01"
 +++
@@ -21,8 +21,8 @@ As always, the complete source code is on [GitHub]. Please file [issues] for any
 
 > **Note**: This post describes how to handle exceptions using naked functions (see [“Handling Exceptions with Naked Functions”] for an overview). Our new way of handling exceptions can be found in the [“Handling Exceptions”] post.
 
-[“Handling Exceptions with Naked Functions”]: @/first-edition/extra/naked-exceptions/_index.md
+[“Handling Exceptions with Naked Functions”]: @/edition-1/extra/naked-exceptions/_index.md
-[“Handling Exceptions”]: @/first-edition/posts/09-handling-exceptions/index.md
+[“Handling Exceptions”]: @/edition-1/posts/09-handling-exceptions/index.md
 
 ## Introduction
 Most exceptions are fatal and can't be resolved. For example, we can't return from a divide-by-zero exception in a reasonable way. However, there are some exceptions that we can resolve:
@@ -42,7 +42,7 @@ The breakpoint exception is commonly used in debuggers: When the user sets a bre
 
 For our use case, we don't need to overwrite any instructions (it wouldn't even be possible since we [set the page table flags] to read-only). Instead, we just want to print a message when the breakpoint instruction is executed and then continue the program.
 
-[set the page table flags]: @/first-edition/posts/07-remap-the-kernel/index.md#using-the-correct-flags
+[set the page table flags]: @/edition-1/posts/07-remap-the-kernel/index.md#using-the-correct-flags
 
 ### Catching Breakpoints
 Let's start by defining a handler function for the breakpoint exception:
@@ -216,7 +216,7 @@ Instead of the expected _“It did not crash”_ message after the breakpoint ex
 ### Debugging
 Let's debug it using GDB. For that we execute `make debug` in one terminal (which starts QEMU with the `-s -S` flags) and then `make gdb` (which starts and connects GDB) in a second terminal. For more information about GDB debugging, check out our [Set Up GDB] guide.
 
-[Set Up GDB]: @/first-edition/extra/set-up-gdb/index.md
+[Set Up GDB]: @/edition-1/extra/set-up-gdb/index.md
 
 First we want to check if our `iretq` was successful. Therefore we set a breakpoint on the `println!("It did not crash line!")` statement in `src/lib.rs`. Let's assume that it's on line 61:
 
@@ -304,7 +304,7 @@ Unfortunately, Rust does not support such a calling convention. It was [proposed
 
 [interrupt calling conventions]: https://github.com/rust-lang/rfcs/pull/1275
 [Naked functions]: https://github.com/rust-lang/rfcs/blob/master/text/1201-naked-fns.md
-[naked fn post]: @/first-edition/extra/naked-exceptions/02-better-exception-messages/index.md#naked-functions
+[naked fn post]: @/edition-1/extra/naked-exceptions/02-better-exception-messages/index.md#naked-functions
 
 ### A naked wrapper function
 
@@ -574,7 +574,7 @@ It doesn't compile anymore. The error tells us that the Rust compiler no longer
 The [core library] is implicitly linked to all `no_std` crates and contains things such as `Result`, `Option`, and iterators. We've used that library without problems since [the very beginning], so why is it no longer available?
 
 [core library]: https://doc.rust-lang.org/nightly/core/index.html
-[the very beginning]: @/first-edition/posts/03-set-up-rust/index.md
+[the very beginning]: @/edition-1/posts/03-set-up-rust/index.md
 
 The problem is that the core library is distributed together with the Rust compiler as a _precompiled_ library. So it is only valid for the host triple, which is `x86_64-unknown-linux-gnu` in our case. If we want to compile code for other targets, we need to recompile `core` for these targets first.
 

blog/content/edition-1/extra/naked-exceptions/_index.md

@@ -0,0 +1,7 @@
++++
+title = "Handling Exceptions using naked Functions"
+sort_by = "weight"
+template = "edition-1/handling-exceptions-with-naked-fns.html"
+insert_anchor_links = "left"
+aliases = ["first-edition/extra/naked-exceptions/index.html"]
++++

blog/content/edition-1/posts/01-multiboot-kernel/index.md

@@ -4,7 +4,7 @@ weight = 1
 path = "multiboot-kernel"
 aliases = ["multiboot-kernel.html", "/2015/08/18/multiboot-kernel/", "/rust-os/multiboot-kernel.html"]
 date  = 2015-08-18
-template = "first-edition/page.html"
+template = "edition-1/page.html"
 +++
 
 This post explains how to create a minimal x86 operating system kernel using the Multiboot standard. In fact, it will just boot and print `OK` to the screen. In subsequent blog posts we will extend it using the [Rust] programming language.
@@ -187,7 +187,7 @@ Idx Name      Size      VMA               LMA               File off  Algn
 ```
 _Note_: The `ld` and `objdump` commands are platform specific. If you're _not_ working on x86_64 architecture, you will need to [cross compile binutils]. Then use `x86_64‑elf‑ld` and `x86_64‑elf‑objdump` instead of `ld` and `objdump`.
 
-[cross compile binutils]: @/first-edition/extra/cross-compile-binutils.md
+[cross compile binutils]: @/edition-1/extra/cross-compile-binutils.md
 
 ## Creating the ISO
 All PC BIOSes know how to boot from a CD-ROM, so we want to create a bootable CD-ROM image, containing our kernel and the GRUB bootloader's files, in a single file called an [ISO](https://en.wikipedia.org/wiki/ISO_image). Make the following directory structure and copy the `kernel.bin` to the right place:
@@ -315,7 +315,7 @@ Now we can invoke `make` and all updated assembly files are compiled and linked.
 
 In the [next post] we will create a page table and do some CPU configuration to switch to the 64-bit [long mode].
 
-[next post]: @/first-edition/posts/02-entering-longmode/index.md
+[next post]: @/edition-1/posts/02-entering-longmode/index.md
 [long mode]: https://en.wikipedia.org/wiki/Long_mode
 
 ## Footnotes

blog/content/edition-1/posts/02-entering-longmode/index.md

@@ -4,14 +4,14 @@ weight = 2
 path = "entering-longmode"
 aliases = ["entering-longmode.html", "/2015/08/25/entering-longmode/", "/rust-os/entering-longmode.html"]
 date  = 2015-08-25
-template = "first-edition/page.html"
+template = "edition-1/page.html"
 [extra]
 updated = "2015-10-29"
 +++
 
 In the [previous post] we created a minimal multiboot kernel. It just prints `OK` and hangs. The goal is to extend it and call 64-bit [Rust] code. But the CPU is currently in [protected mode] and allows only 32-bit instructions and up to 4GiB memory. So we need to set up _Paging_ and switch to the 64-bit [long mode] first.
 
-[previous post]: @/first-edition/posts/01-multiboot-kernel/index.md
+[previous post]: @/edition-1/posts/01-multiboot-kernel/index.md
 [Rust]: https://www.rust-lang.org/
 [protected mode]: https://en.wikipedia.org/wiki/Protected_mode
 [long mode]: https://en.wikipedia.org/wiki/Long_mode
@@ -39,7 +39,7 @@ error:
 At address `0xb8000` begins the so-called [VGA text buffer]. It's an array of screen characters that are displayed by the graphics card. A [future post] will cover the VGA buffer in detail and create a Rust interface to it. But for now, manual bit-fiddling is the easiest option.
 
 [VGA text buffer]: https://en.wikipedia.org/wiki/VGA-compatible_text_mode
-[future post]: @/first-edition/posts/04-printing-to-screen/index.md
+[future post]: @/edition-1/posts/04-printing-to-screen/index.md
 
 A screen character consists of a 8 bit color code and a 8 bit [ASCII] character. We used the color code `4f` for all characters, which means white text on red background. `0x52` is an ASCII `R`, `0x45` is an `E`, `0x3a` is a `:`, and `0x20` is a space. The second space is overwritten by the given ASCII byte. Finally the CPU is stopped with the `hlt` instruction.
 
@@ -492,8 +492,8 @@ _Congratulations_! You have successfully wrestled through this CPU configuration
 #### One Last Thing
 Above, we reloaded the code segment register `cs` with the new GDT offset. However, the data segment registers `ss`, `ds`, `es`, `fs`, and `gs` still contain the data segment offsets of the old GDT. This isn't necessarily bad, since they're ignored by almost all instructions in 64-bit mode. However, there are a few instructions that expect a valid data segment descriptor _or the null descriptor_ in those registers. An example is the the [iretq] instruction that we'll need in the [_Returning from Exceptions_] post.
 
-[iretq]: @/first-edition/extra/naked-exceptions/03-returning-from-exceptions/index.md#the-iretq-instruction
+[iretq]: @/edition-1/extra/naked-exceptions/03-returning-from-exceptions/index.md#the-iretq-instruction
-[_Returning from Exceptions_]: @/first-edition/extra/naked-exceptions/03-returning-from-exceptions/index.md
+[_Returning from Exceptions_]: @/edition-1/extra/naked-exceptions/03-returning-from-exceptions/index.md
 
 To avoid future problems, we reload all data segment registers with null:
 
@@ -515,7 +515,7 @@ long_mode_start:
 It's time to finally leave assembly behind and switch to [Rust]. Rust is a systems language without garbage collections that guarantees memory safety. Through a real type system and many abstractions it feels like a high-level language but can still be low-level enough for OS development. The [next post] describes the Rust setup.
 
 [Rust]: https://www.rust-lang.org/
-[next post]: @/first-edition/posts/03-set-up-rust/index.md
+[next post]: @/edition-1/posts/03-set-up-rust/index.md
 
 ## Footnotes
 [^hardware_lookup]: In the x86 architecture, the page tables are _hardware walked_, so the CPU will look at the table on its own when it needs a translation. Other architectures, for example MIPS, just throw an exception and let the OS translate the virtual address.

blog/content/edition-1/posts/03-set-up-rust/index.md

@@ -4,15 +4,15 @@ weight = 3
 path = "set-up-rust"
 aliases = ["set-up-rust.html", "setup-rust.html", "/2015/09/02/setup-rust/", "/rust-os/setup-rust.html"]
 date  = 2015-09-02
-template = "first-edition/page.html"
+template = "edition-1/page.html"
 [extra]
 updated = "2017-04-12"
 +++
 
 In the previous posts we created a [minimal Multiboot kernel][multiboot post] and [switched to Long Mode][long mode post]. Now we can finally switch to [Rust] code. Rust is a high-level language without runtime. It allows us to not link the standard library and write bare metal code. Unfortunately the setup is not quite hassle-free yet.
 
-[multiboot post]: @/first-edition/posts/01-multiboot-kernel/index.md
+[multiboot post]: @/edition-1/posts/01-multiboot-kernel/index.md
-[long mode post]: @/first-edition/posts/02-entering-longmode/index.md
+[long mode post]: @/edition-1/posts/02-entering-longmode/index.md
 [Rust]: https://www.rust-lang.org/
 
 <!-- more -->
@@ -92,7 +92,7 @@ Let's define some properties of our target system:
 - **No SSE**: Our target might not have [SSE] support. Even if it does, we probably don't want to use SSE instructions in our kernel, because it makes interrupt handling much slower. We will explain this in detail in the [“Handling Exceptions”] post.
 - **No hardware floats**: The `x86_64` architecture uses SSE instructions for floating point operations, which we don't want to use (see the previous point). So we also need to avoid hardware floating point operations in our kernel. Instead, we will use _soft floats_, which are basically software functions that emulate floating point operations using normal integers.
 
-[“Handling Exceptions”]: @/first-edition/posts/09-handling-exceptions/index.md
+[“Handling Exceptions”]: @/edition-1/posts/09-handling-exceptions/index.md
 
 ### Target Specifications
 Rust allows us to define [custom targets] through a JSON configuration file. A minimal target specification equal to `x86_64-unknown-linux-gnu` (the default 64-bit Linux target) looks like this:
@@ -486,10 +486,10 @@ Some notes:
 ### Stack Overflows
 Since we still use the small 64 byte [stack from the last post], we must be careful not to [overflow] it. Normally, Rust tries to avoid stack overflows through _guard pages_: The page below the stack isn't mapped and such a stack overflow triggers a page fault (instead of silently overwriting random memory). But we can't unmap the page below our stack right now since we currently use only a single big page. Fortunately the stack is located just above the page tables. So some important page table entry would probably get overwritten on stack overflow and then a page fault occurs, too.
 
-[stack from the last post]: @/first-edition/posts/02-entering-longmode/index.md#creating-a-stack
+[stack from the last post]: @/edition-1/posts/02-entering-longmode/index.md#creating-a-stack
 [overflow]: https://en.wikipedia.org/wiki/Stack_overflow
 
 ## What's next?
 Until now we write magic bits to some memory location when we want to print something to screen. In the [next post] we create a abstraction for the VGA text buffer that allows us to print strings in different colors and provides a simple interface.
 
-[next post]: @/first-edition/posts/04-printing-to-screen/index.md
+[next post]: @/edition-1/posts/04-printing-to-screen/index.md

blog/content/edition-1/posts/04-printing-to-screen/index.md

@@ -4,14 +4,14 @@ weight = 4
 path = "printing-to-screen"
 aliases = ["printing-to-screen.html", "/2015/10/23/printing-to-screen/", "/rust-os/printing-to-screen.html"]
 date  = 2015-10-23
-template = "first-edition/page.html"
+template = "edition-1/page.html"
 [extra]
 updated = "2016-10-31"
 +++
 
 In the [previous post] we switched from assembly to [Rust], a systems programming language that provides great safety. But so far we are using unsafe features like [raw pointers] whenever we want to print to screen. In this post we will create a Rust module that provides a safe and easy-to-use interface for the VGA text buffer. It will support Rust's [formatting macros], too.
 
-[previous post]: @/first-edition/posts/03-set-up-rust/index.md
+[previous post]: @/edition-1/posts/03-set-up-rust/index.md
 [Rust]: https://www.rust-lang.org/
 [raw pointers]: https://doc.rust-lang.org/book/raw-pointers.html
 [formatting macros]: https://doc.rust-lang.org/std/fmt/#related-macros
@@ -642,7 +642,7 @@ In the next posts we will map the kernel pages correctly so that accessing `0x0`
 
 The [next post] describes the Multiboot information structure and creates a frame allocator using the information about memory areas.
 
-[next post]: @/first-edition/posts/05-allocating-frames/index.md
+[next post]: @/edition-1/posts/05-allocating-frames/index.md
 
 ## Other Rust OS Projects
 Now that you know the very basics of OS development in Rust, you should also check out the following projects:
@@ -658,7 +658,7 @@ _Note_: You need to [cross compile binutils] to build it (or you create some sym
 
 [Rust Bare-Bones Kernel]: https://github.com/thepowersgang/rust-barebones-kernel
 [higher half]: https://wiki.osdev.org/Higher_Half_Kernel
-[cross compile binutils]: @/first-edition/extra/cross-compile-binutils.md
+[cross compile binutils]: @/edition-1/extra/cross-compile-binutils.md
 [RustOS]: https://github.com/RustOS-Fork-Holding-Ground/RustOS
 ["Tifflin" Experimental Kernel]:https://github.com/thepowersgang/rust_os
 [Redox]: https://github.com/redox-os/redox

blog/content/edition-1/posts/05-allocating-frames/index.md

@@ -4,7 +4,7 @@ weight = 5
 path = "allocating-frames"
 aliases = ["allocating-frames.html"]
 date  = 2015-11-15
-template = "first-edition/page.html"
+template = "edition-1/page.html"
 +++
 
 In this post we create an allocator that provides free physical frames for a future paging module. To get the required information about available and used memory we use the Multiboot information structure. Additionally, we improve the `panic` handler to print the corresponding message and source line.
@@ -430,10 +430,10 @@ Now we have a working frame allocator. It is a bit rudimentary and cannot free f
 ## What's next?
 The [next post] will be about paging again. We will use the frame allocator to create a safe module that allows us to switch page tables and map pages. Then we will use this module and the information from the Elf-sections tag to remap the kernel correctly.
 
-[next post]: @/first-edition/posts/06-page-tables/index.md
+[next post]: @/edition-1/posts/06-page-tables/index.md
 
 ## Recommended Posts
 Eric Kidd started the [Bare Metal Rust] series last week. Like this post, it builds upon the code from [Printing to Screen], but tries to support keyboard input instead of wrestling through memory management details.
 
 [Bare Metal Rust]: http://www.randomhacks.net/bare-metal-rust/
-[Printing to Screen]: @/first-edition/posts/04-printing-to-screen/index.md
+[Printing to Screen]: @/edition-1/posts/04-printing-to-screen/index.md

blog/content/edition-1/posts/06-page-tables/index.md

@@ -4,7 +4,7 @@ weight = 6
 path = "page-tables"
 aliases = ["page-tables.html", "modifying-page-tables.html"]
 date  = 2015-12-09
-template = "first-edition/page.html"
+template = "edition-1/page.html"
 +++
 
 In this post we will create a paging module, which allows us to access and modify the 4-level page table. We will explore recursive page table mapping and use some Rust features to make it safe. Finally we will create functions to translate virtual addresses and to map and unmap pages.
@@ -52,7 +52,7 @@ pub struct Page {
 ```
 We import the `PAGE_SIZE` and define a constant for the number of entries per table. To make future function signatures more expressive, we can use the type aliases `PhysicalAddress` and `VirtualAddress`. The `Page` struct is similar to the `Frame` struct in the [previous post], but represents a virtual page instead of a physical frame.
 
-[previous post]: @/first-edition/posts/05-allocating-frames/index.md#a-memory-module
+[previous post]: @/edition-1/posts/05-allocating-frames/index.md#a-memory-module
 
 ### Page Table Entries
 To model page table entries, we create a new `entry` submodule:
@@ -652,7 +652,7 @@ pub struct ActivePageTable {
 ```
 We can't store the `Table<Level4>` directly because it needs to be at a special memory location (like the [VGA text buffer]). We could use a raw pointer or `&mut` instead of [Unique], but Unique indicates ownership better.
 
-[VGA text buffer]: @/first-edition/posts/04-printing-to-screen/index.md#the-text-buffer
+[VGA text buffer]: @/edition-1/posts/04-printing-to-screen/index.md#the-text-buffer
 [Unique]: https://doc.rust-lang.org/1.10.0/core/ptr/struct.Unique.html
 
 Because the `ActivePageTable` owns the unique recursive mapped P4 table, there must be only one `ActivePageTable` instance. Thus we make the constructor function unsafe:
@@ -881,7 +881,7 @@ This post has become pretty long. So let's summarize what we've done:
 ## What's next?
 In the [next post] we will extend this module and add a function to modify inactive page tables. Through that function, we will create a new page table hierarchy that maps the kernel correctly using 4KiB pages. Then we will switch to the new table to get a safer kernel environment.
 
-[next post]: @/first-edition/posts/07-remap-the-kernel/index.md
+[next post]: @/edition-1/posts/07-remap-the-kernel/index.md
 
 Afterwards, we will use this paging module to build a heap allocator. This will allow us to use allocation and collection types such as `Box` and `Vec`.
 

blog/content/edition-1/posts/07-remap-the-kernel/index.md

@@ -4,7 +4,7 @@ weight = 7
 path = "remap-the-kernel"
 aliases = ["remap-the-kernel.html"]
 date  = 2016-01-01
-template = "first-edition/page.html"
+template = "edition-1/page.html"
 [extra]
 updated = "2016-03-06"
 +++
@@ -21,18 +21,18 @@ As always, you can find the source code on [GitHub]. Don't hesitate to file issu
 
 In the [previous post], we had a strange bug in the `unmap` function. Its reason was a silent stack overflow, which corrupted the page tables. Fortunately, our kernel stack is right above the page tables so that we noticed the overflow relatively quickly. This won't be the case when we add threads with new stacks in the future. Then a silent stack overflow could overwrite some data without us noticing. But eventually some completely unrelated function fails because a variable changed its value.
 
-[previous post]: @/first-edition/posts/06-page-tables/index.md
+[previous post]: @/edition-1/posts/06-page-tables/index.md
 
 As you can imagine, these kinds of bugs are horrendous to debug. For that reason we will create a new hierarchical page table in this post, which has _guard page_ below the stack. A guard page is basically an unmapped page that causes a page fault when accessed. Thus we can catch stack overflows right when they happen.
 
 Also, we will use the [information about kernel sections] to map the various sections individually instead of blindly mapping the first gigabyte. To improve safety even further, we will set the correct page table flags for the various sections. Thus it won't be possible to modify the contents of `.text` or to execute code from `.data` anymore.
 
-[information about kernel sections]: @/first-edition/posts/05-allocating-frames/index.md#kernel-elf-sections
+[information about kernel sections]: @/edition-1/posts/05-allocating-frames/index.md#kernel-elf-sections
 
 ## Preparation
 There are many things that can go wrong when we switch to a new table. Therefore it's a good idea to [set up a debugger][set up gdb]. You should not need it when you follow this post, but it's good to know how to debug a problem when it occurs[^fn-debug-notes].
 
-[set up gdb]: @/first-edition/extra/set-up-gdb/index.md
+[set up gdb]: @/edition-1/extra/set-up-gdb/index.md
 
 We also update the `Page` and `Frame` types to make our lives easier. The `Page` struct gets some derived traits:
 
@@ -281,7 +281,7 @@ pub fn map_table_frame(&mut self,
 ```
 This function interprets the given frame as a page table frame and returns a `Table` reference. We return a table of level 1 because it [forbids calling the `next_table` methods][some clever solution]. Calling `next_table` must not be possible since it's not a page of the recursive mapping. To be able to return a `Table<Level1>`, we need to make the `Level1` enum in `memory/paging/table.rs` public.
 
-[some clever solution]: @/first-edition/posts/06-page-tables/index.md#some-clever-solution
+[some clever solution]: @/edition-1/posts/06-page-tables/index.md#some-clever-solution
 
 
 The `unsafe` block is safe since the `VirtualAddress` returned by the `map` function is always valid and the type cast just reinterprets the frame's content.
@@ -554,7 +554,7 @@ First, we create a temporary page at page number `0xcafebabe`. We could use `0xd
 
 Then we use the `with` function to temporary change the recursive mapping and execute the closure as if the `new_table` were active. This allows us to map the sections in the new table without changing the active mapping. To get the kernel sections, we use the [Multiboot information structure].
 
-[Multiboot information structure]: @/first-edition/posts/05-allocating-frames/index.md#the-multiboot-information-structure
+[Multiboot information structure]: @/edition-1/posts/05-allocating-frames/index.md#the-multiboot-information-structure
 
 Let's resolve the above `TODO` by identity mapping the sections:
 
@@ -829,8 +829,8 @@ These lines are the important ones. We can read many useful information from the
 [osdev exception overview]: https://wiki.osdev.org/Exceptions
 [page fault]: https://wiki.osdev.org/Exceptions#Page_Fault
 [page fault error code]: https://wiki.osdev.org/Exceptions#Error_code
-[GDT segment]: @/first-edition/posts/02-entering-longmode/index.md#loading-the-gdt
+[GDT segment]: @/edition-1/posts/02-entering-longmode/index.md#loading-the-gdt
-[VGA text buffer]: @/first-edition/posts/04-printing-to-screen/index.md#the-vga-text-buffer
+[VGA text buffer]: @/edition-1/posts/04-printing-to-screen/index.md#the-vga-text-buffer
 
 So let's find out which function caused the exception:
 
@@ -882,7 +882,7 @@ Now we should see the `NEW TABLE!!!` message (and also the `It did not crash!` l
 ### Fixing the Frame Allocator
 The same problem as above occurs when we try to use our [AreaFrameAllocator] again. Try to add the following to `rust_main` after switching to the new table:
 
-[AreaFrameAllocator]: @/first-edition/posts/05-allocating-frames/index.md#the-allocator
+[AreaFrameAllocator]: @/edition-1/posts/05-allocating-frames/index.md#the-allocator
 
 ```rust
 // in src/lib.rs
@@ -1028,7 +1028,7 @@ The final step is to create a guard page for our kernel stack.
 
 The decision to place the kernel stack right above the page tables was already useful to detect a silent stack overflow in the [previous post][silent stack overflow]. Now we profit from it again. Let's look at our assembly `.bss` section again to understand why:
 
-[silent stack overflow]: @/first-edition/posts/06-page-tables/index.md
+[silent stack overflow]: @/edition-1/posts/06-page-tables/index.md
 
 ```nasm
 ; in src/arch/x86_64/boot.asm
@@ -1089,7 +1089,7 @@ Unfortunately stack probes require compiler support. They already work on Window
 ## What's next?
 Now that we have a (mostly) safe kernel stack and a working page table module, we can add a virtual memory allocator. The [next post] will explore Rust's allocator API and create a very basic allocator. At the end of that post, we will be able to use Rust's allocation and collections types such as [Box], [Vec], or even [BTreeMap].
 
-[next post]: @/first-edition/posts/08-kernel-heap/index.md
+[next post]: @/edition-1/posts/08-kernel-heap/index.md
 [Box]: https://doc.rust-lang.org/nightly/alloc/boxed/struct.Box.html
 [Vec]: https://doc.rust-lang.org/1.10.0/collections/vec/struct.Vec.html
 [BTreeMap]: https://doc.rust-lang.org/1.10.0/collections/btree_map/struct.BTreeMap.html

blog/content/edition-1/posts/08-kernel-heap/index.md

@@ -4,15 +4,15 @@ weight = 8
 path = "kernel-heap"
 aliases = ["kernel-heap.html"]
 date  = 2016-04-11
-template = "first-edition/page.html"
+template = "edition-1/page.html"
 [extra]
 updated = "2017-11-19"
 +++
 
 In the previous posts we created a [frame allocator] and a [page table module]. Now we are ready to create a kernel heap and a memory allocator. Thus, we will unlock `Box`, `Vec`, `BTreeMap`, and the rest of the [alloc] crate.
 
-[frame allocator]: @/first-edition/posts/05-allocating-frames/index.md
+[frame allocator]: @/edition-1/posts/05-allocating-frames/index.md
-[page table module]: @/first-edition/posts/06-page-tables/index.md
+[page table module]: @/edition-1/posts/06-page-tables/index.md
 [alloc]: https://doc.rust-lang.org/nightly/alloc/index.html
 
 <!-- more -->
@@ -333,7 +333,7 @@ let heap_test = Box::new(42);
 
 When we run it, a triple fault occurs and causes permanent rebooting. Let's try debug it using QEMU and objdump as described [in the previous post][qemu debugging]:
 
-[qemu debugging]: @/first-edition/posts/07-remap-the-kernel/index.md#debugging
+[qemu debugging]: @/edition-1/posts/07-remap-the-kernel/index.md#debugging
 
 ```
 > qemu-system-x86_64 -d int -no-reboot -cdrom build/os-x86_64.iso
@@ -461,8 +461,8 @@ That's it. Now our `memory::init` function can only be called once. The macro wo
 ### Mapping the Heap
 Now we're ready to map the heap pages. In order to do it, we need access to the `ActivePageTable` or `Mapper` instance (see the [page table] and [kernel remapping] posts). For that we return it from the `paging::remap_the_kernel` function:
 
-[page table]: @/first-edition/posts/06-page-tables/index.md
+[page table]: @/edition-1/posts/06-page-tables/index.md
-[kernel remapping]: @/first-edition/posts/07-remap-the-kernel/index.md
+[kernel remapping]: @/edition-1/posts/07-remap-the-kernel/index.md
 
 ```rust
 // in src/memory/paging/mod.rs
@@ -737,4 +737,4 @@ Now we're able to use heap storage in our kernel without leaking memory. This al
 ## What's next?
 This post concludes the section about memory management for now. We will revisit this topic eventually, but now it's time to explore other topics. The upcoming posts will be about CPU exceptions and interrupts. We will catch all page, double, and triple faults and create a driver to read keyboard input. The [next post] starts by setting up a so-called _Interrupt Descriptor Table_.
 
-[next post]: @/first-edition/posts/09-handling-exceptions/index.md
+[next post]: @/edition-1/posts/09-handling-exceptions/index.md

blog/content/edition-1/posts/09-handling-exceptions/index.md

@@ -4,7 +4,7 @@ weight = 9
 path = "handling-exceptions"
 aliases = ["handling-exceptions.html"]
 date  = 2017-03-26
-template = "first-edition/page.html"
+template = "edition-1/page.html"
 +++
 
 In this post, we start exploring CPU exceptions. Exceptions occur in various erroneous situations, for example when accessing an invalid memory address or when dividing by zero. To catch them, we have to set up an _interrupt descriptor table_ that provides handler functions. At the end of this post, our kernel will be able to catch [breakpoint exceptions] and to resume normal execution afterwards.
@@ -229,7 +229,7 @@ The breakpoint exception is commonly used in debuggers: When the user sets a bre
 
 For our use case, we don't need to overwrite any instructions (it wouldn't even be possible since we [set the page table flags] to read-only). Instead, we just want to print a message when the breakpoint instruction is executed and then continue the program.
 
-[set the page table flags]: @/first-edition/posts/07-remap-the-kernel/index.md#using-the-correct-flags
+[set the page table flags]: @/edition-1/posts/07-remap-the-kernel/index.md#using-the-correct-flags
 
 So let's create a simple `breakpoint_handler` function and add it to our IDT:
 
@@ -461,7 +461,7 @@ The documentation of the [`Idt`] struct and the [OSDev Wiki][osdev wiki exceptio
 ## Too much Magic?
 The `x86-interrupt` calling convention and the [`Idt`] type made the exception handling process relatively straightforward and painless. If this was too much magic for you and you like to learn all the gory details of exception handling, we got you covered: Our [“Handling Exceptions with Naked Functions”] series shows how to handle exceptions without the `x86-interrupt` calling convention and also creates its own `Idt` type. Historically, these posts were the main exception handling posts before the `x86-interrupt` calling convention and the `x86_64` crate existed.
 
-[“Handling Exceptions with Naked Functions”]: @/first-edition/extra/naked-exceptions/_index.md
+[“Handling Exceptions with Naked Functions”]: @/edition-1/extra/naked-exceptions/_index.md
 
 ## What's next?
 We've successfully caught our first exception and returned from it! The next step is to add handlers for other common exceptions such as page faults. We also need to make sure that we never cause a [triple fault], since it causes a complete system reset. The next post explains how we can avoid this by correctly catching [double faults].

blog/content/edition-1/posts/10-double-faults/index.md

@@ -4,7 +4,7 @@ weight = 10
 path = "double-faults"
 aliases = ["double-faults.html"]
 date  = 2017-01-02
-template = "first-edition/page.html"
+template = "edition-1/page.html"
 +++
 
 In this post we explore double faults in detail. We also set up an _Interrupt Stack Table_ to catch double faults on a separate kernel stack. This way, we can completely prevent triple faults, even on kernel stack overflow.
@@ -20,7 +20,7 @@ As always, the complete source code is available on [GitHub]. Please file [issue
 ## 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]: @/first-edition/posts/09-handling-exceptions/index.md#the-interrupt-descriptor-table
+[IDT]: @/edition-1/posts/09-handling-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.
 
@@ -119,7 +119,7 @@ For example, what happens if… :
 3. a divide-by-zero handler causes a breakpoint exception, but the breakpoint handler is swapped out?
 4. our kernel overflows its stack and the [guard page] is hit?
 
-[guard page]: @/first-edition/posts/07-remap-the-kernel/index.md#creating-a-guard-page
+[guard page]: @/edition-1/posts/07-remap-the-kernel/index.md#creating-a-guard-page
 
 Fortunately, the AMD64 manual ([PDF][AMD64 manual]) has an exact definition (in Section 8.2.9). According to it, a “double fault exception _can_ occur when a second exception occurs during the handling of a prior (first) exception handler”. The _“can”_ is important: Only very specific combinations of exceptions lead to a double fault. These combinations are:
 
@@ -155,7 +155,7 @@ Let's look at the fourth question:
 
 When our kernel overflows its stack and hits the guard page, a _page fault_ occurs. The CPU looks up the page fault handler in the IDT and tries to push the [exception stack frame] onto the stack. However, our current stack pointer still points to the non-present guard page. Thus, a second page fault occurs, which causes a double fault (according to the above table).
 
-[exception stack frame]: @/first-edition/posts/09-handling-exceptions/index.md#the-exception-stack-frame
+[exception stack frame]: @/edition-1/posts/09-handling-exceptions/index.md#the-exception-stack-frame
 
 So the CPU tries to call our _double fault handler_ now. However, on a double fault the CPU tries to push the exception stack frame, too. Our stack pointer still points to the guard page, so a _third_ page fault occurs, which causes a _triple fault_ and a system reboot. So our current double fault handler can't avoid a triple fault in this case.
 
@@ -199,7 +199,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]: @/first-edition/posts/09-handling-exceptions/index.md#the-interrupt-descriptor-table
+[IDT entry]: @/edition-1/posts/09-handling-exceptions/index.md#the-interrupt-descriptor-table
 
 ### Allocating a new Stack
 In order to fill an Interrupt Stack Table later, we need a way to allocate new stacks. Therefore we extend our `memory` module with a new `stack_allocator` submodule:
@@ -230,7 +230,7 @@ impl StackAllocator {
 ```
 We create a simple `StackAllocator` that allocates stacks from a given range of pages (`PageIter` is an Iterator over a range of pages; we introduced it [in the kernel heap post].).
 
-[in the kernel heap post]:  @/first-edition/posts/08-kernel-heap/index.md#mapping-the-heap
+[in the kernel heap post]:  @/edition-1/posts/08-kernel-heap/index.md#mapping-the-heap
 
 We add a `alloc_stack` method that allocates a new stack:
 
@@ -285,8 +285,8 @@ impl StackAllocator {
 ```
 The method takes mutable references to the [ActivePageTable] and a [FrameAllocator], since it needs to map the new virtual stack pages to physical frames. We define that the stack size is a multiple of the page size.
 
-[ActivePageTable]: @/first-edition/posts/06-page-tables/index.md#page-table-ownership
+[ActivePageTable]: @/edition-1/posts/06-page-tables/index.md#page-table-ownership
-[FrameAllocator]: @/first-edition/posts/05-allocating-frames/index.md#a-frame-allocator
+[FrameAllocator]: @/edition-1/posts/05-allocating-frames/index.md#a-frame-allocator
 
 Instead of operating directly on `self.range`, we [clone] it and only write it back on success. This way, subsequent stack allocations can still succeed if there are pages left (e.g., a call with `size_in_pages = 3` can still succeed after a failed call with `size_in_pages = 100`).
 
@@ -297,7 +297,7 @@ In order to be able to clone `PageIter`, we add a `#[derive(Clone)]` to its defi
 The actual allocation is straightforward: First, we choose the next page as [guard page]. Then we choose the next `size_in_pages` pages as stack pages using [Iterator::nth]. If all three variables are `Some`, the allocation succeeded and we map the stack pages to physical frames using [ActivePageTable::map]. The guard page remains unmapped.
 
 [Iterator::nth]: https://doc.rust-lang.org/nightly/core/iter/trait.Iterator.html#method.nth
-[ActivePageTable::map]: @/first-edition/posts/06-page-tables/index.md#more-mapping-functions
+[ActivePageTable::map]: @/edition-1/posts/06-page-tables/index.md#more-mapping-functions
 
 Finally, we create and return a new `Stack`, which we define as follows:
 
@@ -505,7 +505,7 @@ The Global Descriptor Table (GDT) is a relict that was used for [memory segmenta
 
 We already created a GDT [when switching to long mode]. Back then, we used assembly to create valid code and data segment descriptors, which were required to enter 64-bit mode. We could just edit that assembly file and add an additional TSS descriptor. However, we now have the expressiveness of Rust, so let's do it in Rust instead.
 
-[when switching to long mode]: @/first-edition/posts/02-entering-longmode/index.md#the-global-descriptor-table
+[when switching to long mode]: @/edition-1/posts/02-entering-longmode/index.md#the-global-descriptor-table
 
 We start by creating a new `interrupts::gdt` submodule. For that we need to rename the `src/interrupts.rs` file to `src/interrupts/mod.rs`. Then we can create a new submodule:
 

blog/content/first-edition/_index.md

@@ -1,4 +0,0 @@
-+++
-title = "First Edition"
-template = "first-edition/index.html"
-+++

blog/content/first-edition/extra/naked-exceptions/_index.md

@@ -1,6 +0,0 @@
-+++
-title = "Handling Exceptions using naked Functions"
-sort_by = "weight"
-template = "first-edition/handling-exceptions-with-naked-fns.html"
-insert_anchor_links = "left"
-+++

blog/content/news/2018-03-09-pure-rust.md

@@ -12,7 +12,7 @@ Over the past six months we've been working on a second edition of this blog. Ou
 
 The [first edition] required several C-tools for building:
 
-[first edition]: @/first-edition/_index.md
+[first edition]: @/edition-1/_index.md
 
 - We used the [`GRUB`] bootloader for booting our kernel. To create a bootable disk/CD image we used the [`grub-mkrescue`] tool, which is very difficult to get to run on Windows.
 - The [`xorriso`] program was also required, because it is used by `grub-mkrescue`.
@@ -23,7 +23,7 @@ The [first edition] required several C-tools for building:
 [`GRUB`]: https://www.gnu.org/software/grub/
 [`grub-mkrescue`]: https://www.gnu.org/software/grub/manual/grub/html_node/Invoking-grub_002dmkrescue.html
 [`xorriso`]: https://www.gnu.org/software/xorriso/
-[entering long mode]: @/first-edition/posts/02-entering-longmode/index.md
+[entering long mode]: @/edition-1/posts/02-entering-longmode/index.md
 [`nasm`]: https://www.nasm.us/xdoc/2.13.03/html/nasmdoc1.html
 [`ld`]: https://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_3.html
 [linker script]: https://sourceware.org/binutils/docs/ld/Scripts.html

blog/content/second-edition/posts/02-minimal-rust-kernel/index.fa.md

@@ -83,7 +83,7 @@ rtl = true
 
 به دلیل این اشکالات ما تصمیم گرفتیم از GRUB یا استاندارد Multiboot استفاده نکنیم. با این حال، ما قصد داریم پشتیبانی Multiboot را به ابزار [bootimage] خود اضافه کنیم، به طوری که امکان بارگذاری هسته شما بر روی یک سیستم با بوت‌لودر GRUB نیز وجود داشته باشد. اگر علاقه‌مند به نوشتن هسته سازگار با Multiboot هستید، [نسخه اول] مجموعه پست‌های این وبلاگ را بررسی کنید.
 
-[نسخه اول]: @/first-edition/_index.md
+[نسخه اول]: @/edition-1/_index.md
 
 ### UEFI
 

blog/content/second-edition/posts/02-minimal-rust-kernel/index.ja.md

@@ -80,7 +80,7 @@ x86には2つのファームウェアの標準規格があります："Basic Inp
 
 これらの欠点を考慮し、私達はGRUBとMultiboot標準規格を使わないことに決めました。しかし、あなたのカーネルをGRUBシステム上で読み込めるように、私達の[bootimage]ツールにMultibootのサポートを追加することも計画しています。Multiboot準拠なカーネルを書きたい場合は、このブログシリーズの[第1版][first edition]をご覧ください。
 
-[first edition]: @/first-edition/_index.md
+[first edition]: @/edition-1/_index.md
 
 ### UEFI
 

blog/content/second-edition/posts/02-minimal-rust-kernel/index.md

@@ -76,7 +76,7 @@ To make a kernel Multiboot compliant, one just needs to insert a so-called [Mult
 
 Because of these drawbacks we decided to not use GRUB or the Multiboot standard. However, we plan to add Multiboot support to our [bootimage] tool, so that it's possible to load your kernel on a GRUB system too. If you're interested in writing a Multiboot compliant kernel, check out the [first edition] of this blog series.
 
-[first edition]: @/first-edition/_index.md
+[first edition]: @/edition-1/_index.md
 
 ### UEFI
 

blog/content/second-edition/posts/05-cpu-exceptions/index.md

@@ -456,9 +456,9 @@ blog_os::interrupts::test_breakpoint_exception...	[ok]
 ## Too much Magic?
 The `x86-interrupt` calling convention and the [`InterruptDescriptorTable`] type made the exception handling process relatively straightforward and painless. If this was too much magic for you and you like to learn all the gory details of exception handling, we got you covered: Our [“Handling Exceptions with Naked Functions”] series shows how to handle exceptions without the `x86-interrupt` calling convention and also creates its own IDT type. Historically, these posts were the main exception handling posts before the `x86-interrupt` calling convention and the `x86_64` crate existed. Note that these posts are based on the [first edition] of this blog and might be out of date.
 
-[“Handling Exceptions with Naked Functions”]: @/first-edition/extra/naked-exceptions/_index.md
+[“Handling Exceptions with Naked Functions”]: @/edition-1/extra/naked-exceptions/_index.md
 [`InterruptDescriptorTable`]: https://docs.rs/x86_64/0.12.1/x86_64/structures/idt/struct.InterruptDescriptorTable.html
-[first edition]: @/first-edition/_index.md
+[first edition]: @/edition-1/_index.md
 
 ## What's next?
 We've successfully caught our first exception and returned from it! The next step is to ensure that we catch all exceptions, because an uncaught exception causes a fatal [triple fault], which leads to a system reset. The next post explains how we can avoid this by correctly catching [double faults].

blog/static/css/edition-1/main.css

@@ -0,0 +1,455 @@
+@font-face {
+  font-family: "Iosevka";
+  src: url("/fonts/iosevka-regular.woff2") format("woff2"), url("/fonts/iosevka-regular.woff") format("woff");
+  font-weight: normal;
+  font-style: normal;
+  font-display: swap;
+}
+
+h1 code, h2 code, h3 code, h4 code, h5 code, h6 code {
+  padding: 0;
+  color: #a0565c;
+  font-size: 95%;
+  background-color: inherit;
+}
+
+.masthead-title {
+  font-size: 1.25rem;
+  display: inline;
+}
+
+.masthead p {
+  font-size: 1.25rem;
+  display: inline;
+  margin: 0;
+  margin-left: 1rem;
+  padding: 0;
+  line-height: 1;
+}
+
+.front-page-introduction {
+  margin-bottom: 2rem;
+}
+
+.navigation {
+  float: right;
+}
+
+.navigation img {
+  height: 1em;
+  vertical-align: baseline;
+  display: inline-block;
+  margin: 0;
+  padding: 0;
+  border-radius: 0;
+}
+
+main img {
+  max-width: 100%;
+  margin: auto;
+}
+
+.post {
+  margin-bottom: 2em;
+}
+
+.post:last-child {
+  margin-bottom: 0em;
+}
+
+.frontpage-section {
+  margin-bottom: 2rem;
+}
+
+.posts {
+  padding: 1.5rem 1rem 0.5rem 1rem;
+  border-radius: 10px;
+  margin-bottom: 2rem;
+  margin-left: -0.5rem;
+  margin-right: -0.5rem;
+}
+
+.posts.neutral {
+  border: 2px solid #999;
+}
+
+.posts.subscribe {
+  border: 2px solid #aaa;
+}
+
+.posts.edition-1 {
+  border: 2px solid #aaa;
+  background-color: #99ff0022;
+}
+
+.posts.bare-bones {
+  border: 2px solid #66f;
+}
+
+.posts.memory-management {
+  border: 2px solid #fc0
+}
+
+.posts.exceptions {
+  border: 2px solid #f66;
+}
+
+.posts.multitasking {
+  border: 2px solid #556b2f;
+}
+
+.posts hr {
+  margin: 2rem 0;
+}
+
+.post-summary {
+  margin-bottom: 1rem;
+}
+
+.post-summary p {
+  display: inline;
+}
+
+.read-more {
+  margin-left: 5px;
+}
+
+.no-translation {
+  margin-top: .3rem;
+  color: #999999;
+}
+
+.post-category {
+  margin-right: 0.5rem;
+  text-transform: uppercase;
+  font-size: 0.8rem;
+  text-align: right;
+}
+
+.post-category.bare-bones {
+  color: #55d;
+}
+
+.post-category.memory-management {
+  color: #990;
+}
+
+.post-category.exceptions {
+  color: #f33;
+}
+
+.post-category.multitasking {
+  color: #556b2f;
+}
+
+.post-footer-support {
+  margin-top: 2rem;
+}
+
+.PageNavigation {
+  font-size: 0.9em;
+  display: table;
+  width: 100%;
+  overflow: hidden;
+}
+
+.PageNavigation a {
+  display: table-cell;
+}
+
+.PageNavigation .previous {
+  text-align: left;
+}
+
+.PageNavigation .next {
+  text-align: right;
+}
+
+footer.footer {
+  margin-top: 1rem;
+  margin-bottom: 1rem;
+}
+
+.footnotes {
+  font-size: 85%;
+}
+
+.footnotes li {
+  margin-bottom: 1rem;
+}
+
+sup, sub {
+  line-height: 0;
+}
+
+a.anchorjs-link:hover {
+    text-decoration: none;
+}
+
+#toc-aside {
+  display: none;
+}
+
+#toc-inline summary {
+  margin-bottom: .2rem;
+}
+
+aside#all-posts-link {
+  font-size: 90%;
+  margin-top: 0.5rem;
+}
+
+@media (min-width: 80rem) {
+  #toc-inline {
+    display: none;
+  }
+
+  #toc-aside {
+    display: block;
+    width: 12rem;
+    position: sticky;
+    float: left;
+    top: 3.5rem;
+    margin-top: -4rem;
+    margin-left: -15rem;
+    font-size: 90%;
+    line-height: 1.2;
+  }
+
+  #toc-aside li > a, #toc-aside h2 {
+    opacity: .5;
+    transition: opacity .5s;
+  }
+
+  #toc-aside:hover li > a, #toc-aside:hover h2 {
+    opacity: 1;
+  }
+
+  #toc-aside li.active > a {
+    font-weight: bold;
+  }
+
+  #toc-aside h2 {
+    font-size: 110%;
+    margin-bottom: .2rem;
+  }
+
+  #toc-aside ol {
+    margin: 0 0 .2rem 0;
+    padding: 0 0 0 1rem;
+    list-style:none;
+  }
+
+  #toc-aside ol li a:before {
+    content: "";
+    border-color: transparent #008eef;
+    border-style: solid;
+    border-width: 0.35em 0 0.35em 0.45em;
+    display: block;
+    height: 0;
+    width: 0;
+    left: -1em;
+    top: 0.9em;
+    position: relative;
+  }
+
+  #toc-aside.coarse li ol {
+    display: none;
+  }
+
+  aside.page-aside-right {
+    position: absolute;
+    min-width: 11rem;
+    max-width: 17rem;
+    top: 4rem;
+    margin-left: 45rem;
+    margin-right: 2rem;
+    font-size: 90%;
+  }
+
+  aside.page-aside-right .block {
+    margin-bottom: 1.5rem;
+  }
+
+  aside.page-aside-right h2 {
+    font-size: 110%;
+    margin-bottom: .2rem;
+  }
+
+  aside.page-aside-right ul {
+    margin: 0 0 .2rem 0;
+    padding: 0 0 0 1rem;
+  }
+
+  aside.page-aside-right ul li {
+    margin-top: .5rem;
+  }
+
+  aside#all-posts-link {
+    position: fixed;
+    top: 1.25rem;
+    margin-top: 0;
+    margin-left: -15rem;
+  }
+}
+
+aside.page-aside-right time {
+  color: #9a9a9a;
+}
+
+a code {
+  color: #268bd2;
+}
+
+a.zola-anchor {
+  opacity: 0;
+  position: absolute;
+  margin-left: -1.5em;
+  padding-right: 1em;
+  font-size: 0.6em;
+  vertical-align: baseline;
+  line-height: 2em;
+}
+
+:hover>a.zola-anchor {
+  opacity: 1;
+  text-decoration: none;
+}
+
+a.zola-anchor:hover {
+  text-decoration: none;
+}
+
+div.note {
+  padding: .7rem 1rem;
+  margin: 1rem .2rem;
+  border: 2px solid #6ad46a;
+  border-radius: 5px;
+  background-color: #99ff991f;
+}
+
+div.note p:last-child {
+  margin-bottom: 0;
+}
+
+div.warning {
+  padding: .7rem 1rem;
+  margin: 1rem .2rem;
+  border: 2px solid orange;
+  border-radius: 5px;
+  background-color: #ffa50022;
+}
+
+div.warning p:last-child {
+  margin-bottom: 0;
+}
+
+form.subscribe {
+  margin: 1rem;
+}
+
+div.subscribe-fields {
+  display: flex;
+}
+
+form.subscribe input {
+  padding: .5rem;
+  border: 1px solid #e5e5e5;
+}
+
+form.subscribe input[type=email] {
+  flex: 1;
+}
+
+form.subscribe input[type=submit] {
+  padding: .25rem .5rem;
+  cursor: pointer;
+}
+
+/* Asides */
+aside.post_aside {
+  font-style: italic;
+  padding: 0rem 1rem 0rem;
+  margin: .8rem 0;
+  border-left: .1rem solid #e5e5e5;
+  border-right: .1rem solid #e5e5e5;
+}
+
+details summary {
+  cursor: pointer;
+}
+
+details summary h3, details summary h4, details summary h5, details summary h6 {
+  display: inline;
+}
+
+.gh-repo-box {
+  border: 1px solid #d1d5da;
+  border-radius: 3px;
+  padding: 16px;
+  margin-top: 0.5rem;
+  color: #586069;
+  font-size: 80%;
+}
+
+.gh-repo-box .repo-link {
+  color: #0366d6;
+  font-weight: 600;
+  font-size: 120%;
+}
+
+.gh-repo-box .subtitle {
+  margin-bottom: 16px;
+}
+
+.gh-repo-box .stars-forks {
+  margin-bottom: 0;
+}
+
+.gh-repo-box .stars-forks a {
+  color: #586069;
+}
+
+.gh-repo-box .stars-forks a:hover {
+  color: #0366d6;
+  text-decoration: none;
+}
+
+.gh-repo-box .stars-forks svg {
+  vertical-align: text-bottom;
+  fill: currentColor;
+}
+
+.gh-repo-box .stars {
+  display: inline-block;
+}
+
+.gh-repo-box .forks {
+  display: inline-block;
+  margin-left: 16px;
+}
+
+.gh-repo-box .sponsor {
+  display: inline-block;
+  margin-left: 16px;
+}
+
+.hidden {
+  display: none;
+}
+
+.toc-comments-link {
+  margin-top: .5rem;
+}
+
+h5 {
+  font-style: italic;
+  font-size: 0.9rem;
+}
+.gray {
+  color: gray;
+}
+
+a strong {
+  color: #268bd2;
+}

blog/static/css/edition-1/poole.css

@@ -0,0 +1,406 @@
+/*
+ *                        ___
+ *                       /\_ \
+ *  _____     ___     ___\//\ \      __
+ * /\ '__`\  / __`\  / __`\\ \ \   /'__`\
+ * \ \ \_\ \/\ \_\ \/\ \_\ \\_\ \_/\  __/
+ *  \ \ ,__/\ \____/\ \____//\____\ \____\
+ *   \ \ \/  \/___/  \/___/ \/____/\/____/
+ *    \ \_\
+ *     \/_/
+ *
+ * Designed, built, and released under MIT license by @mdo. Learn more at
+ * https://github.com/poole/poole.
+ */
+
+
+/*
+ * Contents
+ *
+ * Body resets
+ * Custom type
+ * Messages
+ * Container
+ * Masthead
+ * Posts and pages
+ * Pagination
+ * Reverse layout
+ * Themes
+ */
+
+
+/*
+ * Body resets
+ *
+ * Update the foundational and global aspects of the page.
+ */
+
+* {
+  -webkit-box-sizing: border-box;
+     -moz-box-sizing: border-box;
+          box-sizing: border-box;
+}
+
+html,
+body {
+  margin: 0;
+  padding: 0;
+}
+
+html {
+  font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
+  line-height: 1.5;
+}
+
+body {
+  color: #515151;
+  background-color: #fff;
+  -webkit-text-size-adjust: 100%;
+      -ms-text-size-adjust: 100%;
+}
+
+/* No `:visited` state is required by default (browsers will use `a`) */
+a {
+  color: #268bd2;
+  text-decoration: none;
+}
+/* `:focus` is linked to `:hover` for basic accessibility */
+a:hover,
+a:focus {
+  text-decoration: underline;
+}
+
+/* Headings */
+h1, h2, h3, h4, h5, h6 {
+  margin-bottom: .5rem;
+  font-weight: bold;
+  line-height: 1.25;
+  color: #313131;
+  text-rendering: optimizeLegibility;
+}
+h1 {
+  font-size: 2rem;
+}
+h2 {
+  margin-top: 1rem;
+  font-size: 1.5rem;
+}
+h3 {
+  margin-top: 1.5rem;
+  font-size: 1.25rem;
+}
+h4, h5, h6 {
+  margin-top: 1rem;
+  font-size: 1rem;
+}
+
+/* Body text */
+p {
+  margin-top: 0;
+  margin-bottom: 1rem;
+}
+
+strong {
+  color: #303030;
+}
+
+
+/* Lists */
+ul, ol, dl {
+  margin-top: 0;
+  margin-bottom: 1rem;
+}
+
+/* Nested lists */
+li ul, li ol, li dl {
+  margin-bottom: 0;
+}
+
+li ul + p, li ol + p, li dl + p {
+  margin-top: 1rem;
+}
+
+dt {
+  font-weight: bold;
+}
+dd {
+  margin-bottom: .5rem;
+}
+
+/* Misc */
+hr {
+  position: relative;
+  margin: 1.5rem 0;
+  border: 0;
+  border-top: 1px solid #eee;
+  border-bottom: 1px solid #fff;
+}
+
+abbr {
+  font-size: 90%;
+  font-weight: bold;
+  color: #555;
+  text-transform: uppercase;
+}
+abbr[title] {
+  cursor: help;
+  border-bottom: 1px dotted #e5e5e5;
+}
+
+/* Code */
+code,
+pre {
+  font-family: "Iosevka", monospace;
+}
+code {
+  padding: .25em .5em;
+  font-size: 90%;
+  color: #bf616a;
+  background-color: #f9f9f9;
+  border-radius: 3px;
+}
+pre {
+  display: block;
+  margin-top: 0;
+  margin-bottom: 1rem;
+  padding: .5rem;
+  font-size: .9rem;
+  line-height: 1.4;
+  white-space: pre;
+  overflow: auto;
+  word-wrap: normal;
+  background-color: #f9f9f9;
+}
+pre code {
+  padding: 0;
+  font-size: 100%;
+  color: inherit;
+  background-color: transparent;
+}
+.highlight {
+  margin-bottom: 1rem;
+  border-radius: 4px;
+}
+.highlight pre {
+  margin-bottom: 0;
+}
+
+/* Quotes */
+blockquote {
+  padding: .5rem 1rem;
+  margin: .8rem 0;
+  color: #7a7a7a;
+  border-left: .25rem solid #e5e5e5;
+}
+blockquote p:last-child {
+  margin-bottom: 0;
+}
+@media (min-width: 30rem) {
+  blockquote {
+    padding-right: 5rem;
+    padding-left: 1.25rem;
+  }
+}
+
+img {
+  display: block;
+  margin: 0 0 1rem;
+  border-radius: 5px;
+  max-width: 100%;
+  color: grey;
+  font-style: italic;
+}
+
+/* Tables */
+table {
+  margin-bottom: 1rem;
+  width: 100%;
+  border: 1px solid #e5e5e5;
+  border-collapse: collapse;
+}
+td,
+th {
+  padding: .25rem .5rem;
+  border: 1px solid #e5e5e5;
+}
+tbody tr:nth-child(odd) td,
+tbody tr:nth-child(odd) th {
+  background-color: #f9f9f9;
+}
+
+
+/*
+ * Custom type
+ *
+ * Extend paragraphs with `.lead` for larger introductory text.
+ */
+
+.lead {
+  font-size: 1.25rem;
+  font-weight: 300;
+}
+
+
+/*
+ * Messages
+ *
+ * Show alert messages to users. You may add it to single elements like a `<p>`,
+ * or to a parent if there are multiple elements to show.
+ */
+
+.message {
+  margin-bottom: 1rem;
+  padding: 1rem;
+  color: #717171;
+  background-color: #f9f9f9;
+}
+
+
+/*
+ * Container
+ *
+ * Center the page content.
+ */
+
+.container {
+  max-width: 45rem;
+  padding-left:  1rem;
+  padding-right: 1rem;
+  margin-left:  auto;
+  margin-right: auto;
+}
+
+
+/*
+ * Masthead
+ *
+ * Super small header above the content for site name and short description.
+ */
+
+.masthead {
+  padding-top:    1rem;
+  padding-bottom: 1rem;
+  margin-bottom:  1rem;
+}
+.masthead-title {
+  margin-top: 0;
+  margin-bottom: 0;
+  color: #505050;
+}
+.masthead-title a {
+  color: #505050;
+}
+.masthead small {
+  font-size: 75%;
+  font-weight: 400;
+  color: #c0c0c0;
+  letter-spacing: 0;
+}
+
+
+/*
+ * Posts and pages
+ *
+ * Each post is wrapped in `.post` and is used on default and post layouts. Each
+ * page is wrapped in `.page` and is only used on the page layout.
+ */
+
+.page {
+  margin-bottom: 4em;
+}
+
+/* Blog post or page title */
+.page-title,
+.post-title,
+.post-title a {
+  color: #303030;
+}
+.page-title,
+.post-title {
+  margin-top: 0;
+}
+
+/* Meta data line below post title */
+.post-date {
+  display: block;
+  margin-top: -.5rem;
+  margin-bottom: 1rem;
+  color: #9a9a9a;
+}
+
+/* Related posts */
+.related {
+  padding-top: 2rem;
+  padding-bottom: 2rem;
+  border-top: 1px solid #eee;
+}
+.related-posts {
+  padding-left: 0;
+  list-style: none;
+}
+.related-posts h3 {
+  margin-top: 0;
+}
+.related-posts li small {
+  font-size: 75%;
+  color: #999;
+}
+.related-posts li a:hover {
+  color: #268bd2;
+  text-decoration: none;
+}
+.related-posts li a:hover small {
+  color: inherit;
+}
+
+
+/*
+ * Pagination
+ *
+ * Super lightweight (HTML-wise) blog pagination. `span`s are provide for when
+ * there are no more previous or next posts to show.
+ */
+
+.pagination {
+  overflow: hidden; /* clearfix */
+  margin-left: -1rem;
+  margin-right: -1rem;
+  font-family: "PT Sans", Helvetica, Arial, sans-serif;
+  color: #ccc;
+  text-align: center;
+}
+
+/* Pagination items can be `span`s or `a`s */
+.pagination-item {
+  display: block;
+  padding: 1rem;
+  border: 1px solid #eee;
+}
+.pagination-item:first-child {
+  margin-bottom: -1px;
+}
+
+/* Only provide a hover state for linked pagination items */
+a.pagination-item:hover {
+  background-color: #f5f5f5;
+}
+
+@media (min-width: 30rem) {
+  .pagination {
+    margin: 3rem 0;
+  }
+  .pagination-item {
+    float: left;
+    width: 50%;
+  }
+  .pagination-item:first-child {
+    margin-bottom: 0;
+    border-top-left-radius:    4px;
+    border-bottom-left-radius: 4px;
+  }
+  .pagination-item:last-child {
+    margin-left: -1px;
+    border-top-right-radius:    4px;
+    border-bottom-right-radius: 4px;
+  }
+}

blog/static/css/main.css

@@ -69,7 +69,7 @@ main img {
   border: 2px solid #aaa;
 }
 
-.posts.first-edition {
+.posts.edition-1 {
   border: 2px solid #aaa;
   background-color: #99ff0022;
 }

blog/static/handling-exceptions-with-naked-fns.html

@@ -1,8 +1,8 @@
 <!DOCTYPE html>
 <html>
     <head>
-        <link rel="canonical" href="/first-edition/extra/naked-exceptions/" />
+        <link rel="canonical" href="/edition-1/extra/naked-exceptions/" />
         <meta http-equiv="content-type" content="text/html; charset=utf-8" />
-        <meta http-equiv="refresh" content="0;url=/first-edition/extra/naked-exceptions/" />
+        <meta http-equiv="refresh" content="0;url=/edition-1/extra/naked-exceptions/" />
     </head>
 </html>

blog/static/js/edition-1/main.js

@@ -0,0 +1,79 @@
+window.onload = function() {
+  show_lang_selector();
+
+  var container = document.querySelector('#toc-aside');
+
+  if (container != null) {
+    resize_toc(container);
+    toc_scroll_position(container);
+    window.onscroll = function() { toc_scroll_position(container) };
+  }
+}
+
+function resize_toc(container) {
+  var containerHeight = container.clientHeight;
+
+  var resize = function() {
+    if (containerHeight > document.documentElement.clientHeight - 100) {
+      container.classList.add('coarse');
+    } else {
+      container.classList.remove('coarse');
+    }
+  };
+  resize();
+
+  var resizeId;
+  window.onresize = function() {
+    clearTimeout(resizeId);
+    resizeId = setTimeout(resize, 300);
+  };
+}
+
+function toc_scroll_position(container) {
+  if (container.offsetParent === null) {
+    // skip computation if ToC is not visible
+    return;
+  }
+  var items = container.querySelectorAll("li")
+
+  // remove active class for all items
+  for (item of container.querySelectorAll("li")) {
+    item.classList.remove("active");
+  }
+
+  // look for active item
+  var site_offset = document.documentElement.scrollTop;
+  var current_toc_item = null;
+  for (item of container.querySelectorAll("li")) {
+    if (item.offsetParent === null) {
+      // skip items that are not visible
+      continue;
+    }
+    var anchor = item.firstElementChild.getAttribute("href");
+    var heading = document.querySelector(anchor);
+    if (heading.offsetTop <= (site_offset + document.documentElement.clientHeight / 3)) {
+      current_toc_item = item;
+    } else {
+      break;
+    }
+  }
+
+  // set active class for current ToC item
+  if (current_toc_item != null) {
+    current_toc_item.classList.add("active");
+  }
+}
+
+function show_lang_selector() {
+  var show_lang_selector = false;
+  for (language_selector of document.querySelectorAll('#language-selector li')) {
+    var lang = language_selector.getAttribute("data-lang-switch-to");
+    if (this.navigator.languages.includes(lang)) {
+      language_selector.classList.remove("hidden");
+      show_lang_selector = true
+    }
+  }
+  if (show_lang_selector) {
+    document.querySelector("#language-selector").classList.remove("hidden")
+  }
+}

blog/templates/edition-1/base.html

@@ -9,11 +9,11 @@
     <meta name="description" content="{{ config.description }}">
     <meta name="author" content="{{ config.extra.author.name }}">
 
-    <link href="/css/poole.css" rel="stylesheet">
+    <link href="/css/edition-1/poole.css" rel="stylesheet">
-    <link href="/css/main.css" rel="stylesheet">
+    <link href="/css/edition-1/main.css" rel="stylesheet">
-    <link href="/css/first-edition-isso.css" rel="stylesheet">
+    <link href="/css/edition-1/isso.css" rel="stylesheet">
 
-    <script async src="/js/main.js"></script>
+    <script async src="/js/edition-1/main.js"></script>
 
     <title>{% block title %}{% endblock title %} (First Edition)</title>
 </head>
@@ -22,7 +22,7 @@
     <div class="container content">
         <header class="masthead">
             <h2 class="masthead-title">
-                <a href="/first-edition" title="Home">{{ config.title }} (First Edition)</a>
+                <a href="/edition-1" title="Home">{{ config.title }} (First Edition)</a>
             </h2>
             <p><small>{{ config.extra.subtitle | replace(from=" ", to="&nbsp;") | safe }}</small></p>
         </header>

blog/templates/edition-1/comments.html

@@ -0,0 +1,31 @@
+{% macro comment(page) %}
+    {% if page.path == "/multiboot-kernel/" %}
+        {% include "edition-1/comments/multiboot-kernel.html" %}
+    {% elif page.path == "/entering-longmode/" %}
+        {% include "edition-1/comments/entering-longmode.html" %}
+    {% elif page.path == "/set-up-rust/" %}
+        {% include "edition-1/comments/set-up-rust.html" %}
+    {% elif page.path == "/printing-to-screen/" %}
+        {% include "edition-1/comments/printing-to-screen.html" %}
+    {% elif page.path == "/allocating-frames/" %}
+        {% include "edition-1/comments/allocating-frames.html" %}
+    {% elif page.path == "/page-tables/" %}
+        {% include "edition-1/comments/page-tables.html" %}
+    {% elif page.path == "/remap-the-kernel/" %}
+        {% include "edition-1/comments/remap-the-kernel.html" %}
+    {% elif page.path == "/kernel-heap/" %}
+        {% include "edition-1/comments/kernel-heap.html" %}
+    {% elif page.path == "/handling-exceptions/" %}
+        {% include "edition-1/comments/handling-exceptions.html" %}
+    {% elif page.path == "/double-faults/" %}
+        {% include "edition-1/comments/double-faults.html" %}
+    {% elif page.path == "/catching-exceptions/" %}
+        {% include "edition-1/comments/catching-exceptions.html" %}
+    {% elif page.path == "/better-exception-messages/" %}
+        {% include "edition-1/comments/better-exception-messages.html" %}
+    {% elif page.path == "/returning-from-exceptions/" %}
+        {% include "edition-1/comments/returning-from-exceptions.html" %}
+    {% else %}
+        No comments.
+    {% endif %}
+{% endmacro comment %}

blog/templates/edition-1/handling-exceptions-with-naked-fns.html

@@ -1,4 +1,4 @@
-{% extends "first-edition/section.html" %}
+{% extends "edition-1/section.html" %}
 
 {% block title %}{{ super() }}{% endblock title %}
 
@@ -6,6 +6,6 @@
 
 {% block introduction %}
 
-    <p>These posts explain how to handle CPU exceptions using naked functions. Historically, these posts were the main exception handling posts before the <code>x86-interrupt</code> calling convention and the <code>x86_64</code> crate existed. Our new way of handling exceptions can be found in the <a href="{{ get_url(path="@/first-edition/posts/09-handling-exceptions/index.md") | safe }}">“Handling Exceptions”</a> post.</p>
+    <p>These posts explain how to handle CPU exceptions using naked functions. Historically, these posts were the main exception handling posts before the <code>x86-interrupt</code> calling convention and the <code>x86_64</code> crate existed. Our new way of handling exceptions can be found in the <a href="{{ get_url(path="@/edition-1/posts/09-handling-exceptions/index.md") | safe }}">“Handling Exceptions”</a> post.</p>
 
 {% endblock introduction %}

blog/templates/edition-1/index.html

@@ -1,11 +1,11 @@
-{% extends "first-edition/base.html" %}
+{% extends "edition-1/base.html" %}
 
 {% import "macros.html" as macros %}
 
 {% block title %}{{ config.title }}{% endblock title %}
 
 {% block main %}
-{% set posts_section = get_section(path = "first-edition/posts/_index.md") %}
+{% set posts_section = get_section(path = "edition-1/posts/_index.md") %}
 {% set posts = posts_section.pages %}
 
 <h1 style="visibility: hidden; height: 0px; margin: 0px; padding: 0px;">Writing an OS in Rust (First Edition)</h1>
@@ -50,7 +50,7 @@
 </div>
 
 <hr>
-{% set extra = get_section(path = "first-edition/extra/_index.md") %}
+{% set extra = get_section(path = "edition-1/extra/_index.md") %}
 <h2>{{ extra.title }}</h2>
 <ul>
     {% for subsection_path in extra.subsections %}

blog/templates/edition-1/page.html

@@ -1,6 +1,6 @@
-{% extends "first-edition/base.html" %}
+{% extends "edition-1/base.html" %}
 
-{% import "first-edition/comments.html" as comments %}
+{% import "edition-1/comments.html" as comments %}
 
 {% block title %}{{ page.title }} | {{ config.title }}{% endblock title %}