michaelkuc6/blog_os
1
0
Fork 0
mirror of https://github.com/phil-opp/blog_os.git synced 2025-12-16 22:37:49 +00:00
Code Issues Projects Releases Wiki Activity

Use zola's page_template feature

Browse Source
This commit is contained in:
Philipp Oppermann
2019-03-14 12:58:10 +01:00
parent c655a61290
commit 82256aaa2f
16 changed files with 15 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
blog/content/second-edition/extra/_index.md
View File

@@ -3,4 +3,5 @@ title = "Extra Content"
insert_anchor_links = "left" insert_anchor_links = "left"
render = false render = false
sort_by = "weight" sort_by = "weight"
page_template = "second-edition/extra.html"
+++ +++

2
blog/content/second-edition/extra/building-on-android/index.md
View File

@@ -1,7 +1,7 @@
+++ +++
title = "Building on Android" title = "Building on Android"
weight = 3 weight = 3
template = "second-edition/extra.html"
+++ +++
I finally managed to get `blog_os` building on my Android phone using [termux](https://termux.com/). This post explains the necessary steps to set it up. I finally managed to get `blog_os` building on my Android phone using [termux](https://termux.com/). This post explains the necessary steps to set it up.

2
blog/content/second-edition/extra/disable-red-zone/index.md
View File

@@ -2,7 +2,7 @@
title = "Disable the Red Zone" title = "Disable the Red Zone"
weight = 1 weight = 1
path = "red-zone" path = "red-zone"
template = "second-edition/extra.html"
+++ +++
The [red zone] is an optimization of the [System V ABI] that allows functions to temporary use the 128 bytes below its stack frame without adjusting the stack pointer: The [red zone] is an optimization of the [System V ABI] that allows functions to temporary use the 128 bytes below its stack frame without adjusting the stack pointer:

2
blog/content/second-edition/extra/disable-simd/index.md
View File

@@ -2,7 +2,7 @@
title = "Disable SIMD" title = "Disable SIMD"
weight = 2 weight = 2
path = "disable-simd" path = "disable-simd"
template = "second-edition/extra.html"
+++ +++
[Single Instruction Multiple Data (SIMD)] instructions are able to perform an operation (e.g. addition) simultaneously on multiple data words, which can speed up programs significantly. The `x86_64` architecture supports various SIMD standards: [Single Instruction Multiple Data (SIMD)] instructions are able to perform an operation (e.g. addition) simultaneously on multiple data words, which can speed up programs significantly. The `x86_64` architecture supports various SIMD standards:

2
blog/content/second-edition/posts/01-freestanding-rust-binary/index.md
View File

@@ -3,7 +3,7 @@ title = "A Freestanding Rust Binary"
weight = 1 weight = 1
path = "freestanding-rust-binary" path = "freestanding-rust-binary"
date = 2018-02-10 date = 2018-02-10
template = "second-edition/page.html"
+++ +++
The first step in creating our own operating system kernel is to create a Rust executable that does not link the standard library. This makes it possible to run Rust code on the [bare metal] without an underlying operating system. The first step in creating our own operating system kernel is to create a Rust executable that does not link the standard library. This makes it possible to run Rust code on the [bare metal] without an underlying operating system.

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

@@ -3,7 +3,7 @@ title = "A Minimal Rust Kernel"
weight = 2 weight = 2
path = "minimal-rust-kernel" path = "minimal-rust-kernel"
date = 2018-02-10 date = 2018-02-10
template = "second-edition/page.html"
+++ +++
In this post we create a minimal 64-bit Rust kernel for the x86 architecture. We build upon the [freestanding Rust binary] from the previous post to create a bootable disk image, that prints something to the screen. In this post we create a minimal 64-bit Rust kernel for the x86 architecture. We build upon the [freestanding Rust binary] from the previous post to create a bootable disk image, that prints something to the screen.

2
blog/content/second-edition/posts/03-vga-text-buffer/index.md
View File

@@ -3,7 +3,7 @@ title = "VGA Text Mode"
weight = 3 weight = 3
path = "vga-text-mode" path = "vga-text-mode"
date = 2018-02-26 date = 2018-02-26
template = "second-edition/page.html"
+++ +++
The [VGA text mode] is a simple way to print text to the screen. In this post, we create an interface that makes its usage safe and simple, by encapsulating all unsafety in a separate module. We also implement support for Rust's [formatting macros]. The [VGA text mode] is a simple way to print text to the screen. In this post, we create an interface that makes its usage safe and simple, by encapsulating all unsafety in a separate module. We also implement support for Rust's [formatting macros].

2
blog/content/second-edition/posts/04-unit-testing/index.md
View File

@@ -3,7 +3,7 @@ title = "Unit Testing"
weight = 4 weight = 4
path = "unit-testing" path = "unit-testing"
date = 2018-04-29 date = 2018-04-29
template = "second-edition/page.html"
+++ +++
This post explores unit testing in `no_std` executables using Rust's built-in test framework. We will adjust our code so that `cargo test` works and add some basic unit tests to our VGA buffer module. This post explores unit testing in `no_std` executables using Rust's built-in test framework. We will adjust our code so that `cargo test` works and add some basic unit tests to our VGA buffer module.

2
blog/content/second-edition/posts/05-integration-tests/index.md
View File

@@ -3,7 +3,7 @@ title = "Integration Tests"
weight = 5 weight = 5
path = "integration-tests" path = "integration-tests"
date = 2018-06-15 date = 2018-06-15
template = "second-edition/page.html"
+++ +++
To complete the testing picture we implement a basic integration test framework, which allows us to run tests on the target system. The idea is to run tests inside QEMU and report the results back to the host through the serial port. To complete the testing picture we implement a basic integration test framework, which allows us to run tests on the target system. The idea is to run tests inside QEMU and report the results back to the host through the serial port.

2
blog/content/second-edition/posts/06-cpu-exceptions/index.md
View File

@@ -3,7 +3,7 @@ title = "CPU Exceptions"
weight = 6 weight = 6
path = "cpu-exceptions" path = "cpu-exceptions"
date = 2018-06-17 date = 2018-06-17
template = "second-edition/page.html"
+++ +++
CPU exceptions occur in various erroneous situations, for example when accessing an invalid memory address or when dividing by zero. To react to 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. CPU exceptions occur in various erroneous situations, for example when accessing an invalid memory address or when dividing by zero. To react to 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.

2
blog/content/second-edition/posts/07-double-faults/index.md
View File

@@ -3,7 +3,7 @@ title = "Double Faults"
weight = 7 weight = 7
path = "double-fault-exceptions" path = "double-fault-exceptions"
date = 2018-06-18 date = 2018-06-18
template = "second-edition/page.html"
+++ +++
This post explores the double fault exception in detail, which occurs when the CPU fails to invoke an exception handler. By handling this exception we avoid fatal _triple faults_ that cause a system reset. To prevent triple faults in all cases we also set up an _Interrupt Stack Table_ to catch double faults on a separate kernel stack. This post explores the double fault exception in detail, which occurs when the CPU fails to invoke an exception handler. By handling this exception we avoid fatal _triple faults_ that cause a system reset. To prevent triple faults in all cases we also set up an _Interrupt Stack Table_ to catch double faults on a separate kernel stack.

2
blog/content/second-edition/posts/08-hardware-interrupts/index.md
View File

@@ -3,7 +3,7 @@ title = "Hardware Interrupts"
weight = 8 weight = 8
path = "hardware-interrupts" path = "hardware-interrupts"
date = 2018-10-22 date = 2018-10-22
template = "second-edition/page.html"
+++ +++
In this post we set up the programmable interrupt controller to correctly forward hardware interrupts to the CPU. To handle these interrupts we add new entries to our interrupt descriptor table, just like we did for our exception handlers. We will learn how to get periodic timer interrupts and how to get input from the keyboard. In this post we set up the programmable interrupt controller to correctly forward hardware interrupts to the CPU. To handle these interrupts we add new entries to our interrupt descriptor table, just like we did for our exception handlers. We will learn how to get periodic timer interrupts and how to get input from the keyboard.

2
blog/content/second-edition/posts/09-paging-introduction/index.md
View File

@@ -3,7 +3,7 @@ title = "Introduction to Paging"
weight = 9 weight = 9
path = "paging-introduction" path = "paging-introduction"
date = 2019-01-14 date = 2019-01-14
template = "second-edition/page.html"
+++ +++
This post introduces _paging_, a very common memory management scheme that we will also use for our operating system. It explains why memory isolation is needed, how _segmentation_ works, what _virtual memory_ is, and how paging solves memory fragmentation issues. It also explores the layout of multilevel page tables on the x86_64 architecture. This post introduces _paging_, a very common memory management scheme that we will also use for our operating system. It explains why memory isolation is needed, how _segmentation_ works, what _virtual memory_ is, and how paging solves memory fragmentation issues. It also explores the layout of multilevel page tables on the x86_64 architecture.

1
blog/content/second-edition/posts/10-paging-implementation/index.md
View File

@@ -3,7 +3,6 @@ title = "Paging Implementation"
weight = 10 weight = 10
path = "paging-implementation" path = "paging-implementation"
date = 2019-03-14 date = 2019-03-14
template = "second-edition/page.html"
+++ +++
This post shows how to implement paging support in our kernel. It first explores different techniques to make the physical page table frames accessible to the kernel and discusses their respective advantages and drawbacks. It then implements an address translation function and a function to create a new mapping. This post shows how to implement paging support in our kernel. It first explores different techniques to make the physical page table frames accessible to the kernel and discusses their respective advantages and drawbacks. It then implements an address translation function and a function to create a new mapping.

1
blog/content/second-edition/posts/_index.md
View File

@@ -3,4 +3,5 @@ title = "Posts"
sort_by = "weight" sort_by = "weight"
insert_anchor_links = "left" insert_anchor_links = "left"
render = false render = false
page_template = "second-edition/page.html"
+++ +++

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

@@ -3,7 +3,7 @@ title = "Advanced Paging"
weight = 10 weight = 10
path = "advanced-paging" path = "advanced-paging"
date = 2019-01-28 date = 2019-01-28
template = "second-edition/page.html"
[extra] [extra]
warning_short = "Deprecated: " warning_short = "Deprecated: "
warning = "This post is deprecated in favor of the [_Paging Implementation_](/paging-implementation) post and will no longer receive updates. See issue [#545](https://github.com/phil-opp/blog_os/issues/545) for reasons for this deprecation." warning = "This post is deprecated in favor of the [_Paging Implementation_](/paging-implementation) post and will no longer receive updates. See issue [#545](https://github.com/phil-opp/blog_os/issues/545) for reasons for this deprecation."