Update blog to 43924afbbf

_posts/2015-08-18-multiboot-kernel.md

@@ -172,7 +172,7 @@ Idx Name          Size      VMA               LMA               File off  Algn
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
 ```
 _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]: {{ site.url }}/cross-compile-binutils.html
+[cross compile binutils]: /cross-compile-binutils.html
 
 ## Creating the ISO
 The last step is to create a bootable ISO image with GRUB. We need to create the following directory structure and copy the `kernel.bin` to the right place:
@@ -211,7 +211,7 @@ Now it's time to boot our OS. We will use [QEMU]:
 ```
 qemu-system-x86_64 -hda os.iso
 ```
-![qemu output]({{ site.url }}/images/qemu-ok.png)
+![qemu output](/images/qemu-ok.png)
 
 Notice the green `OK` in the upper left corner. If it does not work for you, take a look at the comment section.
 
@@ -297,5 +297,5 @@ 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]: {{ site.url }}{{ page.next.url }}
+[next post]: {{ page.next.url }}
 [long mode]: https://en.wikipedia.org/wiki/Long_mode

_posts/2015-08-25-entering-longmode.md

@@ -8,7 +8,7 @@ In the [previous post] we created a minimal multiboot kernel. It just prints `OK
 
 I tried to explain everything in detail and to keep the code as simple as possible. If you have any questions, suggestions, or issues, please leave a comment or [create an issue] on Github. The source code is available in a [repository][source code], too.
 
-[previous post]: {{ site.url }}{{ page.previous.url }}
+[previous post]: {{ page.previous.url }}
 [Rust]: http://www.rust-lang.org/
 [protected mode]: https://en.wikipedia.org/wiki/Protected_mode
 [long mode]: https://en.wikipedia.org/wiki/Long_mode
@@ -34,7 +34,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]: {{ site.url }}{{ page.next.next.url }}
+[future post]: {{ page.next.next.url }}
 
 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.
 
@@ -179,7 +179,7 @@ Each page table contains 512 entries and one entry is 8 bytes, so they fit exact
 
 [^virtual_physical_translation_source]: Image source: [Wikipedia](https://commons.wikimedia.org/wiki/File:X86_Paging_64bit.svg), with modified font size, page table naming, and removed sign extended bits. The modified file is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license.
 
-![translation of virtual to physical addresses in 64 bit mode]({{ site.url }}/images/X86_Paging_64bit.svg)
+![translation of virtual to physical addresses in 64 bit mode](/images/X86_Paging_64bit.svg)
 
 1. Get the address of the P4 table from the CR3 register
 2. Use bits 39-47 (9 bits) as an index into P4 (`2^9 = 512 = number of entries`)
@@ -492,4 +492,4 @@ It's time to finally leave assembly behind[^leave_assembly_behind] and switch to
 [^leave_assembly_behind]: Actually we will still need some assembly in the future, but I'll try to minimize it.
 
 [Rust]: https://www.rust-lang.org/
-[next post]: {{ site.url }}{{ page.next.url }}
+[next post]: {{ page.next.url }}

_posts/2015-09-02-setup-rust.md

@@ -7,8 +7,8 @@ In the previous posts we created a [minimal Multiboot kernel][multiboot post] an
 
 This blog post tries to setup Rust step-by-step and point out the different problems. If you have any questions, problems, or suggestions please [file an issue] or create a comment at the bottom. The code from this post is in a [Github repository], too.
 
-[multiboot post]: {{ site.url }}{{ page.previous.previous.url }}
-[long mode post]: {{ site.url }}{{ page.previous.url }}
+[multiboot post]: {{ page.previous.previous.url }}
+[long mode post]: {{ page.previous.url }}
 [Rust]: https://www.rust-lang.org/
 [file an issue]: https://github.com/phil-opp/blog_os/issues
 [Github repository]: https://github.com/phil-opp/blog_os/tree/setup_rust
@@ -73,7 +73,7 @@ We can now build it using `cargo build`. To make sure, we are building it for th
 cargo build --target=x86_64-unknown-linux-gnu
 ```
 It creates a static library at `target/x86_64-unknown-linux-gnu/debug/libblog_os.a`, which can be linked with our assembly kernel. If you're getting an error about a missing `core` crate, [look here][cross compile libcore].
-[cross compile libcore]: {{ site.url }}/cross-compile-libcore.html
+[cross compile libcore]: /cross-compile-libcore.html
 
 To build and link the rust library on `make`, we extend our `Makefile`([full file][github makefile]):
 
@@ -318,7 +318,7 @@ The code is from the great [OSDev Wiki][osdev sse] again. Notice that it sets/un
 
 When we insert a `call setup_SSE` right before calling `rust_main`, our Rust code will finally work.
 
-[32-bit error function]: {{ site.url }}{{ page.previous.url }}#some-tests
+[32-bit error function]: {{ page.previous.url }}#some-tests
 [osdev sse]: http://wiki.osdev.org/SSE#Checking_for_SSE
 
 ### “OS returned!”
@@ -376,10 +376,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]: {{ site.url }}{{ page.previous.url }}#creating-a-stack
+[stack from the last post]: {{ page.previous.url }}#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]: {{ site.url }}{{ page.next.url }}
+[next post]: {{ page.next.url }}

_posts/2015-10-23-printing-to-screen.md

@@ -5,7 +5,7 @@ redirect_from: "/2015/10/23/printing-to-screen/"
 ---
 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]: {{ site.url }}{{ page.previous.url }}
+[previous post]: {{ page.previous.url }}
 [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
@@ -426,7 +426,7 @@ Now that you know the very basics of OS development in Rust, you should also che
 _Note_: You need to [cross compile binutils] to build it (or you create some symbolic links[^fn-symlink] if you're on x86_64).
 [Rust Bare-Bones Kernel]: https://github.com/thepowersgang/rust-barebones-kernel
 [higher half]: http://wiki.osdev.org/Higher_Half_Kernel
-[cross compile binutils]: {{ site.url }}/cross-compile-binutils.html
+[cross compile binutils]: /cross-compile-binutils.html
 [^fn-symlink]: You will need to symlink `x86_64-none_elf-XXX` to `/usr/bin/XXX` where `XXX` is in {`as`, `ld`, `objcopy`, `objdump`, `strip`}. The `x86_64-none_elf-XXX` files must be in some folder that is in your `$PATH`. But then you can only build for your x86_64 host architecture, so use this hack only for testing.
 
 - [RustOS]: More advanced kernel that supports allocation, keyboard inputs, and threads. It also has a scheduler and a basic network driver.

cross-compile-libcore.md

@@ -7,7 +7,7 @@ So you're getting an ``error: can't find crate for `core` [E0463]`` when using `
 **If you have an x86_64 processor and want a quick fix**, try it with `x86_64-pc-windows-gnu` or `x86_64-apple-darwin` (or simply omit the explicit `--target`).
 
 The idiomatic alternative and the only option for non x86_64 CPUs is described below. Note that you need to [cross compile binutils], too.
-[cross compile binutils]: {{ site.url }}/cross-compile-binutils.html
+[cross compile binutils]: /cross-compile-binutils.html
 
 ## Libcore
 The core library is a dependency-free library that is added implicitly when using `#![no_std]`. It provides basic standard library features like Option or Iterator. The core library is installed together with the rust compiler (just like the std library). But the installed libcore is specific to your architecture. If you aren't working on x86_64 Linux and pass `‑‑target x86_64‑unknown‑linux‑gnu` to cargo, it can't find a x86_64 libcore. To fix this, you can either download it or build it using cargo.