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

Fix remaining dead links

Browse Source
This commit is contained in:
Philipp Oppermann
2019-07-07 11:02:39 +02:00
parent a74c65f8dc
commit 7294471223
8 changed files with 13 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
blog/content/first-edition/extra/naked-exceptions/02-better-exception-messages/index.md
View File

@@ -84,7 +84,7 @@ We're using [inline assembly] here to load the value from the `rsp` register int
- After the third colon, the macro expects so called [clobbers]. We don't change any register values, so we leave it empty too. - After the third colon, the macro expects so called [clobbers]. We don't change any register values, so we leave it empty too.
- The last block (after the 4th colon) specifies options. The `intel` option tells the compiler that our code is in Intel assembly syntax (instead of the default AT&T syntax). - The last block (after the 4th colon) specifies options. The `intel` option tells the compiler that our code is in Intel assembly syntax (instead of the default AT&T syntax).
[clobbers]: https://doc.rust-lang.org/nightly/book/inline-assembly.html#clobbers [clobbers]: https://doc.rust-lang.org/1.10.0/book/inline-assembly.html#clobbers
So the inline assembly loads the stack pointer value to `stack_frame` at the very beginning of our function. Thus we have a pointer to the exception stack frame and are able to pretty-print its `Debug` formatting through the `{:#?}` argument. So the inline assembly loads the stack pointer value to `stack_frame` at the very beginning of our function. Thus we have a pointer to the exception stack frame and are able to pretty-print its `Debug` formatting through the `{:#?}` argument.

2
blog/content/first-edition/extra/naked-exceptions/03-returning-from-exceptions/index.md
View File

@@ -250,7 +250,7 @@ However, there is a major difference between exceptions and function calls: A fu
[Calling conventions] specify the details of a function call. For example, they specify where function parameters are placed (e.g. in registers or on the stack) and how results are returned. On x86_64 Linux, the following rules apply for C functions (specified in the [System V ABI]): [Calling conventions] specify the details of a function call. For example, they specify where function parameters are placed (e.g. in registers or on the stack) and how results are returned. On x86_64 Linux, the following rules apply for C functions (specified in the [System V ABI]):
[Calling conventions]: https://en.wikipedia.org/wiki/Calling_convention [Calling conventions]: https://en.wikipedia.org/wiki/Calling_convention
[System V ABI]: http://refspecs.linuxbase.org/elf/x86-64-abi-0.99.pdf [System V ABI]: http://refspecs.linuxbase.org/elf/gabi41.pdf
- the first six integer arguments are passed in registers `rdi`, `rsi`, `rdx`, `rcx`, `r8`, `r9` - the first six integer arguments are passed in registers `rdi`, `rsi`, `rdx`, `rcx`, `r8`, `r9`
- additional arguments are passed on the stack - additional arguments are passed on the stack

6
blog/content/first-edition/posts/04-printing-to-screen/index.md
View File

@@ -89,7 +89,7 @@ pub enum Color {
``` ```
We use a [C-like enum] here to explicitly specify the number for each color. Because of the `repr(u8)` attribute each enum variant is stored as an `u8`. Actually 4 bits would be sufficient, but Rust doesn't have an `u4` type. We use a [C-like enum] here to explicitly specify the number for each color. Because of the `repr(u8)` attribute each enum variant is stored as an `u8`. Actually 4 bits would be sufficient, but Rust doesn't have an `u4` type.
[C-like enum]: http://rustbyexample.com/custom_types/enum/c_like.html [C-like enum]: https://doc.rust-lang.org/rust-by-example/custom_types/enum/c_like.html
Normally the compiler would issue a warning for each unused variant. By using the `#[allow(dead_code)]` attribute we disable these warnings for the `Color` enum. Normally the compiler would issue a warning for each unused variant. By using the `#[allow(dead_code)]` attribute we disable these warnings for the `Color` enum.
@@ -142,7 +142,7 @@ pub struct Writer {
``` ```
The writer will always write to the last line and shift lines up when a line is full (or on `\n`). The `column_position` field keeps track of the current position in the last row. The current foreground and background colors are specified by `color_code` and a pointer to the VGA buffer is stored in `buffer`. To make it possible to create a `static` Writer later, the `buffer` field stores an `Unique<Buffer>` instead of a plain `*mut Buffer`. [Unique] is a wrapper that implements Send/Sync and is thus usable as a `static`. Since it's unstable, you may need to add the `unique` feature to `lib.rs`: The writer will always write to the last line and shift lines up when a line is full (or on `\n`). The `column_position` field keeps track of the current position in the last row. The current foreground and background colors are specified by `color_code` and a pointer to the VGA buffer is stored in `buffer`. To make it possible to create a `static` Writer later, the `buffer` field stores an `Unique<Buffer>` instead of a plain `*mut Buffer`. [Unique] is a wrapper that implements Send/Sync and is thus usable as a `static`. Since it's unstable, you may need to add the `unique` feature to `lib.rs`:
[Unique]: https://doc.rust-lang.org/nightly/core/ptr/struct.Unique.html [Unique]: https://doc.rust-lang.org/1.10.0/core/ptr/struct.Unique.html
```rust ```rust
// in src/lib.rs // in src/lib.rs
@@ -210,7 +210,7 @@ The reason it that Rust _moves_ values by default instead of copying them like o
To fix it, we can implement the [Copy] trait for the `ColorCode` type. The easiest way to do this is to use the built-in [derive macro]: To fix it, we can implement the [Copy] trait for the `ColorCode` type. The easiest way to do this is to use the built-in [derive macro]:
[Copy]: https://doc.rust-lang.org/nightly/core/marker/trait.Copy.html [Copy]: https://doc.rust-lang.org/nightly/core/marker/trait.Copy.html
[derive macro]: http://rustbyexample.com/trait/derive.html [derive macro]: https://doc.rust-lang.org/rust-by-example/custom_types/enum/c_like.html
```rust ```rust
#[derive(Debug, Clone, Copy)] #[derive(Debug, Clone, Copy)]

2
blog/content/first-edition/posts/09-handling-exceptions/index.md
View File

@@ -274,7 +274,7 @@ This error occurs because the `x86-interrupt` calling convention is still unstab
### Loading the IDT ### Loading the IDT
In order that the CPU uses our new interrupt descriptor table, we need to load it using the [`lidt`] instruction. The `Idt` struct of the `x86_64` provides a [`load`][Idt::load] method function for that. Let's try to use it: In order that the CPU uses our new interrupt descriptor table, we need to load it using the [`lidt`] instruction. The `Idt` struct of the `x86_64` provides a [`load`][Idt::load] method function for that. Let's try to use it:
[`lidt`]: http://x86.renejeschke.de/html/file_module_x86_id_156.html [`lidt`]: https://www.felixcloutier.com/x86/lgdt:lidt
[Idt::load]: https://docs.rs/x86_64/0.1.1/x86_64/structures/idt/struct.Idt.html#method.load [Idt::load]: https://docs.rs/x86_64/0.1.1/x86_64/structures/idt/struct.Idt.html#method.load
```rust ```rust

6
blog/content/first-edition/posts/10-double-faults/index.md
View File

@@ -136,7 +136,7 @@ First Exception | Second Exception
[Page Fault]: http://wiki.osdev.org/Exceptions#Page_Fault [Page Fault]: http://wiki.osdev.org/Exceptions#Page_Fault
[AMD64 manual]: http://developer.amd.com/wordpress/media/2012/10/24593_APM_v21.pdf [AMD64 manual]: https://www.amd.com/system/files/TechDocs/24593.pdf
So for example a divide-by-zero fault followed by a page fault is fine (the page fault handler is invoked), but a divide-by-zero fault followed by a general-protection fault leads to a double fault. So for example a divide-by-zero fault followed by a page fault is fine (the page fault handler is invoked), but a divide-by-zero fault followed by a general-protection fault leads to a double fault.
@@ -357,7 +357,7 @@ impl MemoryController {
The `MemoryController` struct holds the three types that are required for `alloc_stack` and provides a simpler interface (only one argument). The `alloc_stack` wrapper just takes the tree types as `&mut` through [destructuring] and forwards them to the `stack_allocator`. The [ref mut]-s are needed to take the inner fields by mutable reference. Note that we're re-exporting the `Stack` type since it is returned by `alloc_stack`. The `MemoryController` struct holds the three types that are required for `alloc_stack` and provides a simpler interface (only one argument). The `alloc_stack` wrapper just takes the tree types as `&mut` through [destructuring] and forwards them to the `stack_allocator`. The [ref mut]-s are needed to take the inner fields by mutable reference. Note that we're re-exporting the `Stack` type since it is returned by `alloc_stack`.
[destructuring]: https://doc.rust-lang.org/1.10.0/book/patterns.html#destructuring [destructuring]: https://doc.rust-lang.org/1.10.0/book/patterns.html#destructuring
[ref mut]: http://rust-lang.github.io/book/ch18-00-patterns.html#ref-and-ref-mut [ref mut]: https://doc.rust-lang.org/1.30.0/book/second-edition/ch18-03-pattern-syntax.html#creating-references-in-patterns-with-ref-and-ref-mut
The last step is to create a `StackAllocator` and return a `MemoryController` from `memory::init`: The last step is to create a `StackAllocator` and return a `MemoryController` from `memory::init`:
@@ -496,7 +496,7 @@ We define that the 0th IST entry is the double fault stack (any other IST index
Now that we created a new TSS, we need a way to tell the CPU that it should use it. Unfortunately, this is a bit cumbersome, since the TSS is a Task State _Segment_ (for historical reasons). So instead of loading the table directly, we need to add a new segment descriptor to the [Global Descriptor Table] \(GDT). Then we can load our TSS invoking the [`ltr` instruction] with the respective GDT index. Now that we created a new TSS, we need a way to tell the CPU that it should use it. Unfortunately, this is a bit cumbersome, since the TSS is a Task State _Segment_ (for historical reasons). So instead of loading the table directly, we need to add a new segment descriptor to the [Global Descriptor Table] \(GDT). Then we can load our TSS invoking the [`ltr` instruction] with the respective GDT index.
[Global Descriptor Table]: http://www.flingos.co.uk/docs/reference/Global-Descriptor-Table/ [Global Descriptor Table]: http://www.flingos.co.uk/docs/reference/Global-Descriptor-Table/
[`ltr` instruction]: http://x86.renejeschke.de/html/file_module_x86_id_163.html [`ltr` instruction]: https://www.felixcloutier.com/x86/ltr
### The Global Descriptor Table (again) ### The Global Descriptor Table (again)
The Global Descriptor Table (GDT) is a relict that was used for [memory segmentation] before paging became the de facto standard. It is still needed in 64-bit mode for various things such as kernel/user mode configuration or TSS loading. The Global Descriptor Table (GDT) is a relict that was used for [memory segmentation] before paging became the de facto standard. It is still needed in 64-bit mode for various things such as kernel/user mode configuration or TSS loading.

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

@@ -670,7 +670,7 @@ We can't directly return a `MappedPageTable` from the function because it is gen
The [`MappedPageTable::new`] function expects two parameters: a mutable reference to the level 4 page table and a `phys_to_virt` closure that converts a physical frame to a page table pointer `*mut PageTable`. For the first parameter we can reuse our `active_level_4_table` function. For the second parameter, we create a closure that uses the `physical_memory_offset` to perform the conversion. The [`MappedPageTable::new`] function expects two parameters: a mutable reference to the level 4 page table and a `phys_to_virt` closure that converts a physical frame to a page table pointer `*mut PageTable`. For the first parameter we can reuse our `active_level_4_table` function. For the second parameter, we create a closure that uses the `physical_memory_offset` to perform the conversion.
[`MappedPageTable::new`]: https://docs.rs/x86_64/0.7.0/x86_64/structures/paging/struct.MappedPageTable.html#method.new [`MappedPageTable::new`]: https://docs.rs/x86_64/0.7.0/x86_64/structures/paging/mapper/struct.MappedPageTable.html#method.new
We also make the `active_level_4_table` private because it should only be called from the `init` function from now on. We also make the `active_level_4_table` private because it should only be called from the `init` function from now on.
@@ -760,7 +760,7 @@ The `map_to` function can fail, so it returns a [`Result`]. Since this is just s
[`Result`]: https://doc.rust-lang.org/core/result/enum.Result.html [`Result`]: https://doc.rust-lang.org/core/result/enum.Result.html
[`expect`]: https://doc.rust-lang.org/core/result/enum.Result.html#method.expect [`expect`]: https://doc.rust-lang.org/core/result/enum.Result.html#method.expect
[`MapperFlush`]: https://docs.rs/x86_64/0.7.0/x86_64/structures/paging/mapper/struct.MapperFlush.html [`MapperFlush`]: https://docs.rs/x86_64/0.7.0/x86_64/structures/paging/mapper/struct.MapperFlush.html
[`flush`]: https://docs.rs/x86_64/0.7.0/x86_64/structures/paging/struct.MapperFlush.html#method.flush [`flush`]: https://docs.rs/x86_64/0.7.0/x86_64/structures/paging/mapper/struct.MapperFlush.html#method.flush
[must_use]: https://doc.rust-lang.org/std/result/#results-must-be-used [must_use]: https://doc.rust-lang.org/std/result/#results-must-be-used
#### A dummy `FrameAllocator` #### A dummy `FrameAllocator`

2
blog/content/second-edition/posts/10-heap-allocation/index.md
View File

@@ -626,7 +626,7 @@ Of course there are many more allocation and collection types in the `alloc` cra
- [`BTreeMap`] and [`BTreeSet`] - [`BTreeMap`] and [`BTreeSet`]
[`Arc`]: https://doc.rust-lang.org/alloc/sync/struct.Arc.html [`Arc`]: https://doc.rust-lang.org/alloc/sync/struct.Arc.html
[`String`]: https://doc.rust-lang.org/alloc/collections/string/struct.String.html [`String`]: https://doc.rust-lang.org/alloc/string/struct.String.html
[`format!`]: https://doc.rust-lang.org/alloc/macro.format.html [`format!`]: https://doc.rust-lang.org/alloc/macro.format.html
[`LinkedList`]: https://doc.rust-lang.org/alloc/collections/linked_list/struct.LinkedList.html [`LinkedList`]: https://doc.rust-lang.org/alloc/collections/linked_list/struct.LinkedList.html
[`VecDeque`]: https://doc.rust-lang.org/alloc/collections/vec_deque/struct.VecDeque.html [`VecDeque`]: https://doc.rust-lang.org/alloc/collections/vec_deque/struct.VecDeque.html

2
blog/templates/first-edition/comments/printing-to-screen.html
View File

@@ -227,7 +227,7 @@
</path> </path>
</g> </g>
</svg> </svg>
</a><a rel="nofollow" href="#" class="reply">Antworten</a></div><div class="isso-follow-up"></div></div></div></div></div></div><div id="isso-20" class="isso-comment isso-no-votes"><div class="avatar"><svg version="1.1" viewBox="0 0 48 48" preserveAspectRatio="xMinYMin meet" shape-rendering="crispEdges" data-hash="1d800ad10773"><rect x="0" y="0" width="56" height="56" style="fill: #f0f0f0"></rect><rect x="4" y="12" width="8" height="8" style="fill: #9163b6"></rect><rect x="36" y="12" width="8" height="8" style="fill: #9163b6"></rect><rect x="12" y="20" width="8" height="8" style="fill: #9163b6"></rect><rect x="28" y="20" width="8" height="8" style="fill: #9163b6"></rect><rect x="12" y="28" width="8" height="8" style="fill: #9163b6"></rect><rect x="28" y="28" width="8" height="8" style="fill: #9163b6"></rect><rect x="12" y="36" width="8" height="8" style="fill: #9163b6"></rect><rect x="28" y="36" width="8" height="8" style="fill: #9163b6"></rect><rect x="20" y="12" width="8" height="8" style="fill: #9163b6"></rect><rect x="20" y="20" width="8" height="8" style="fill: #9163b6"></rect><rect x="20" y="28" width="8" height="8" style="fill: #9163b6"></rect></svg></div><div class="text-wrapper"><div role="meta" class="isso-comment-header"><span class="author">Chris Latham</span><span class="spacer">•</span><a rel="nofollow" href="#isso-20" class="permalink"><time title="Wed Jun 22 2016 16:02:16 GMT+0200 (Central European Summer Time)" datetime="2016-05-03T14:02:16Z">vor 3 Jahren</time></a><span class="note"></span></div><div class="text"><p>hey, great articles so far!</p><p>i've been following along, and i've run into some issues with the ::core::fmt::Write implementation for our writer class.</p><p>if i add that code in, i get these linker errors:</p><p>core.0.rs:(.text._ZN4core3fmt5write17hdac96890aec66a9aE+0x324): undefined reference to `_Unwind_Resume'</p><p><a rel="nofollow" href="http://core.0.rs">core.0.rs</a>:(.text._ZN4core3fmt5write17hdac96890aec66a9aE+0x3eb): undefined reference to `_Unwind_Resume'</p><p><a rel="nofollow" href="http://core.0.rs">core.0.rs</a>:(.text._ZN4core3fmt5write17hdac96890aec66a9aE+0x3f3): undefined reference to `_Unwind_Resume'</p><p>i've gone back and checked that i set panic to "abort" for both dev and release profiles in my config.toml, the same way you did to fix the unwinding issues. everything seems to match up with what you have. what have i missed?</p><p>thanks in advance.</p></div><div class="isso-comment-footer"><span class="votes">0</span><a rel="nofollow" href="#" class="upvote"><!-- Generator: IcoMoon.io --><svg width="16" height="16" viewBox="0 0 32 32" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" fill="gray"> </a><a rel="nofollow" href="#" class="reply">Antworten</a></div><div class="isso-follow-up"></div></div></div></div></div></div><div id="isso-20" class="isso-comment isso-no-votes"><div class="avatar"><svg version="1.1" viewBox="0 0 48 48" preserveAspectRatio="xMinYMin meet" shape-rendering="crispEdges" data-hash="1d800ad10773"><rect x="0" y="0" width="56" height="56" style="fill: #f0f0f0"></rect><rect x="4" y="12" width="8" height="8" style="fill: #9163b6"></rect><rect x="36" y="12" width="8" height="8" style="fill: #9163b6"></rect><rect x="12" y="20" width="8" height="8" style="fill: #9163b6"></rect><rect x="28" y="20" width="8" height="8" style="fill: #9163b6"></rect><rect x="12" y="28" width="8" height="8" style="fill: #9163b6"></rect><rect x="28" y="28" width="8" height="8" style="fill: #9163b6"></rect><rect x="12" y="36" width="8" height="8" style="fill: #9163b6"></rect><rect x="28" y="36" width="8" height="8" style="fill: #9163b6"></rect><rect x="20" y="12" width="8" height="8" style="fill: #9163b6"></rect><rect x="20" y="20" width="8" height="8" style="fill: #9163b6"></rect><rect x="20" y="28" width="8" height="8" style="fill: #9163b6"></rect></svg></div><div class="text-wrapper"><div role="meta" class="isso-comment-header"><span class="author">Chris Latham</span><span class="spacer">•</span><a rel="nofollow" href="#isso-20" class="permalink"><time title="Wed Jun 22 2016 16:02:16 GMT+0200 (Central European Summer Time)" datetime="2016-05-03T14:02:16Z">vor 3 Jahren</time></a><span class="note"></span></div><div class="text"><p>hey, great articles so far!</p><p>i've been following along, and i've run into some issues with the ::core::fmt::Write implementation for our writer class.</p><p>if i add that code in, i get these linker errors:</p><p>core.0.rs:(.text._ZN4core3fmt5write17hdac96890aec66a9aE+0x324): undefined reference to `_Unwind_Resume'</p><p>core.0.rs:(.text._ZN4core3fmt5write17hdac96890aec66a9aE+0x3eb): undefined reference to `_Unwind_Resume'</p><p>core.0.rs:(.text._ZN4core3fmt5write17hdac96890aec66a9aE+0x3f3): undefined reference to `_Unwind_Resume'</p><p>i've gone back and checked that i set panic to "abort" for both dev and release profiles in my config.toml, the same way you did to fix the unwinding issues. everything seems to match up with what you have. what have i missed?</p><p>thanks in advance.</p></div><div class="isso-comment-footer"><span class="votes">0</span><a rel="nofollow" href="#" class="upvote"><!-- Generator: IcoMoon.io --><svg width="16" height="16" viewBox="0 0 32 32" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" fill="gray">
<g> <g>
<path d="M 24.773,18.299c-0.651-0.669-7.512-7.203-7.512-7.203C 16.912,10.739, 16.456,10.56, 16,10.56c-0.458,0-0.914,0.179-1.261,0.536 c0,0-6.861,6.534-7.514,7.203c-0.651,0.669-0.696,1.872,0,2.586c 0.698,0.712, 1.669,0.77, 2.522,0L 16,14.89l 6.251,5.995 c 0.854,0.77, 1.827,0.712, 2.522,0C 25.47,20.17, 25.427,18.966, 24.773,18.299z"> <path d="M 24.773,18.299c-0.651-0.669-7.512-7.203-7.512-7.203C 16.912,10.739, 16.456,10.56, 16,10.56c-0.458,0-0.914,0.179-1.261,0.536 c0,0-6.861,6.534-7.514,7.203c-0.651,0.669-0.696,1.872,0,2.586c 0.698,0.712, 1.669,0.77, 2.522,0L 16,14.89l 6.251,5.995 c 0.854,0.77, 1.827,0.712, 2.522,0C 25.47,20.17, 25.427,18.966, 24.773,18.299z">
</path> </path>