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 anchor names of internal links

Browse Source
This commit is contained in:
Philipp Oppermann
2019-09-29 15:44:44 +02:00
parent e5b4d501ed
commit c76516db75
7 changed files with 7 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
blog/content/first-edition/posts/02-entering-longmode/index.md
View File

@@ -492,7 +492,7 @@ _Congratulations_! You have successfully wrestled through this CPU configuration
#### One Last Thing #### 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. 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]: @/first-edition/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_]: @/first-edition/extra/naked-exceptions/03-returning-from-exceptions/index.md
To avoid future problems, we reload all data segment registers with null: To avoid future problems, we reload all data segment registers with null:

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

@@ -275,7 +275,7 @@ Now we can rerun the above command with `xbuild` instead of `build`:
We see that `cargo xbuild` cross-compiles the `core`, `compiler_builtin`, and `alloc` libraries for our new custom target. Since these libraries use a lot of unstable features internally, this only works with a [nightly Rust compiler]. Afterwards, `cargo xbuild` successfully compiles our `blog_os` crate. We see that `cargo xbuild` cross-compiles the `core`, `compiler_builtin`, and `alloc` libraries for our new custom target. Since these libraries use a lot of unstable features internally, this only works with a [nightly Rust compiler]. Afterwards, `cargo xbuild` successfully compiles our `blog_os` crate.
[nightly Rust compiler]: @/second-edition/posts/01-freestanding-rust-binary/index.md#installing-rust-nightly [nightly Rust compiler]: #installing-rust-nightly
Now we are able to build our kernel for a bare metal target. However, our `_start` entry point, which will be called by the boot loader, is still empty. So let's output something to screen from it. Now we are able to build our kernel for a bare metal target. However, our `_start` entry point, which will be called by the boot loader, is still empty. So let's output something to screen from it.

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

@@ -438,7 +438,7 @@ name = "stack_overflow"
harness = false harness = false
``` ```
[without a test harness]: @/second-edition/posts/04-testing/index.md#no-harness [without a test harness]: @/second-edition/posts/04-testing/index.md#no-harness-tests
Now `cargo xtest --test stack_overflow` should compile successfully. The test fails of course, since the `unimplemented` macro panics. Now `cargo xtest --test stack_overflow` should compile successfully. The test fails of course, since the `unimplemented` macro panics.

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

@@ -296,7 +296,7 @@ The [`CR2`] register is automatically set by the CPU on a page fault and contain
[`Cr2::read`]: https://docs.rs/x86_64/0.7.5/x86_64/registers/control/struct.Cr2.html#method.read [`Cr2::read`]: https://docs.rs/x86_64/0.7.5/x86_64/registers/control/struct.Cr2.html#method.read
[`PageFaultErrorCode`]: https://docs.rs/x86_64/0.7.5/x86_64/structures/idt/struct.PageFaultErrorCode.html [`PageFaultErrorCode`]: https://docs.rs/x86_64/0.7.5/x86_64/structures/idt/struct.PageFaultErrorCode.html
[LLVM bug]: https://github.com/rust-lang/rust/issues/57270 [LLVM bug]: https://github.com/rust-lang/rust/issues/57270
[`hlt_loop`]: @/second-edition/posts/07-hardware-interrupts/index.md#the [`hlt_loop`]: @/second-edition/posts/07-hardware-interrupts/index.md#the-hlt-instruction
Now we can try to access some memory outside our kernel: Now we can try to access some memory outside our kernel:

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

@@ -192,7 +192,7 @@ Whereas `AAA` is the level 4 index, `BBB` the level 3 index, `CCC` the level 2 i
`SSSSSS` are sign extension bits, which means that they are all copies of bit 47. This is a special requirement for valid addresses on the x86_64 architecture. We explained it in the [previous post][sign extension]. `SSSSSS` are sign extension bits, which means that they are all copies of bit 47. This is a special requirement for valid addresses on the x86_64 architecture. We explained it in the [previous post][sign extension].
[sign extension]: @/second-edition/posts/08-paging-introduction/index.md#paging-on-x86 [sign extension]: @/second-edition/posts/08-paging-introduction/index.md#paging-on-x86-64
We use [octal] numbers for representing the addresses since each octal character represents three bits, which allows us to clearly separate the 9-bit indexes of the different page table levels. This isn't possible with the hexadecimal system where each character represents four bits. We use [octal] numbers for representing the addresses since each octal character represents three bits, which allows us to clearly separate the 9-bit indexes of the different page table levels. This isn't possible with the hexadecimal system where each character represents four bits.

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

@@ -392,7 +392,7 @@ We set the heap size to 100 KiB for now. If we need more space in the future, we
If we tried to use this heap region now, a page fault would occur since the virtual memory region is not mapped to physical memory yet. To resolve this, we create an `init_heap` function that maps the heap pages using the [`Mapper` API] that we introduced in the [_"Paging Implementation"_] post: If we tried to use this heap region now, a page fault would occur since the virtual memory region is not mapped to physical memory yet. To resolve this, we create an `init_heap` function that maps the heap pages using the [`Mapper` API] that we introduced in the [_"Paging Implementation"_] post:
[`Mapper` API]: @/second-edition/posts/09-paging-implementation/index.md#using-mappedpagetable [`Mapper` API]: @/second-edition/posts/09-paging-implementation/index.md#using-offsetpagetable
[_"Paging Implementation"_]: @/second-edition/posts/09-paging-implementation/index.md [_"Paging Implementation"_]: @/second-edition/posts/09-paging-implementation/index.md
```rust ```rust

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

@@ -156,7 +156,7 @@ Whereas `AAA` is the level 4 index, `BBB` the level 3 index, `CCC` the level 2 i
`SSSSSS` are sign extension bits, which means that they are all copies of bit 47. This is a special requirement for valid addresses on the x86_64 architecture. We explained it in the [previous post][sign extension]. `SSSSSS` are sign extension bits, which means that they are all copies of bit 47. This is a special requirement for valid addresses on the x86_64 architecture. We explained it in the [previous post][sign extension].
[sign extension]: @/second-edition/posts/08-paging-introduction/index.md#paging-on-x86 [sign extension]: @/second-edition/posts/08-paging-introduction/index.md#paging-on-x86-64
We use [octal] numbers for representing the addresses since each octal character represents three bits, which allows us to clearly separate the 9-bit indexes of the different page table levels. This isn't possible with the hexadecimal system where each character represents four bits. We use [octal] numbers for representing the addresses since each octal character represents three bits, which allows us to clearly separate the 9-bit indexes of the different page table levels. This isn't possible with the hexadecimal system where each character represents four bits.