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

Update 'Paging Implementation' post for bootloader 0.5.1

Browse Source
This commit is contained in:
Philipp Oppermann
2019-04-06 17:49:31 +02:00
parent b8667c45dd
commit 6015feb511
1 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -47,11 +47,11 @@ To implement the approach, we will need support from the bootloader, so we'll co
### Dependency Updates
This post requires version 0.4.0 or later of the `bootloader` dependency and version 0.5.2 or later of the `x86_64` dependency. You can update the dependencies in your `Cargo.toml`:
This post requires version 0.5.1 or later of the `bootloader` dependency and version 0.5.2 or later of the `x86_64` dependency. You can update the dependencies in your `Cargo.toml`:
```toml
[dependencies]
bootloader = "0.4.0"
bootloader = "0.5.1"
x86_64 = "0.5.2"
```
@@ -305,7 +305,7 @@ We choose the first approach for our kernel since it is simple, platform-indepen
```toml
[dependencies]
bootloader = { version = "0.4.0", features = ["map_physical_memory"]}
bootloader = { version = "0.5.1", features = ["map_physical_memory"]}
```
With this feature enabled, the bootloader maps the complete physical memory to some unused virtual address range. To communicate the virtual address range to our kernel, the bootloader passes a _boot information_ structure.
@@ -342,7 +342,7 @@ Since our `_start` function is called externally from the bootloader, no checkin
To make sure that the entry point function has always the correct signature that the bootloader expects, the `bootloader` crate provides an [`entry_point`] macro that provides a type-checked way to define a Rust function as the entry point. Let's rewrite our entry point function to use this macro:
[`entry_point`]: https://docs.rs/bootloader/0.4.0/bootloader/macro.entry_point.html
[`entry_point`]: https://docs.rs/bootloader/0.5.1/bootloader/macro.entry_point.html
```rust
// in src/main.rs
@@ -889,7 +889,7 @@ This function uses iterator combinator methods to transform the initial `MemoryM
- The third step is the most complicated: We convert each range to an iterator through the `into_iter` method and then choose every 4096th address using [`step_by`]. Since 4096 bytes (= 4 KiB) is the page size, we get the start address of each frame. The bootloader page aligns all usable memory areas so that we don't need any alignment or rounding code here. By using [`flat_map`] instead of `map`, we get an `Iterator<Item = u64>` instead of an `Iterator<Item = Iterator<Item = u64>>`.
- In the final step, we convert the start addresses to `PhysFrame` types to construct the desired `Iterator<Item = PhysFrame>`. We then use this iterator to create and return a new `BootInfoFrameAllocator`.
[`MemoryRegion`]: https://docs.rs/bootloader/0.4.0/bootloader/bootinfo/struct.MemoryRegion.html
[`MemoryRegion`]: https://docs.rs/bootloader/0.5.1/bootloader/bootinfo/struct.MemoryRegion.html
[`filter`]: https://doc.rust-lang.org/core/iter/trait.Iterator.html#method.filter
[`map`]: https://doc.rust-lang.org/core/iter/trait.Iterator.html#method.map
[range syntax]: https://doc.rust-lang.org/core/ops/struct.Range.html