Merge pull request #664 from phil-opp/update-deps

Update to bootloader 0.8.0
This commit is contained in:
Philipp Oppermann
2019-09-11 11:10:53 +02:00
committed by GitHub
2 changed files with 6 additions and 6 deletions

View File

@@ -361,7 +361,7 @@ Instead of writing our own bootloader, which is a project on its own, we use the
# in Cargo.toml # in Cargo.toml
[dependencies] [dependencies]
bootloader = "0.6.4" bootloader = "0.8.0"
``` ```
Adding the bootloader as dependency is not enough to actually create a bootable disk image. The problem is that we need to link our kernel with the bootloader after compilation, but cargo has no support for [post-build scripts]. Adding the bootloader as dependency is not enough to actually create a bootable disk image. The problem is that we need to link our kernel with the bootloader after compilation, but cargo has no support for [post-build scripts].
@@ -371,10 +371,10 @@ Adding the bootloader as dependency is not enough to actually create a bootable
To solve this problem, we created a tool named `bootimage` that first compiles the kernel and bootloader, and then links them together to create a bootable disk image. To install the tool, execute the following command in your terminal: To solve this problem, we created a tool named `bootimage` that first compiles the kernel and bootloader, and then links them together to create a bootable disk image. To install the tool, execute the following command in your terminal:
``` ```
cargo install bootimage --version "^0.7.3" cargo install bootimage --version "^0.7.7"
``` ```
The `^0.7.3` is a so-called [_caret requirement_], which means "version `0.7.3` or a later compatible version". So if we find a bug and publish version `0.7.4` or `0.7.5`, cargo would automatically use the latest version, as long as it is still a version `0.7.x`. However, it wouldn't choose version `0.8.0`, because it is not considered as compatible. Note that dependencies in your `Cargo.toml` are caret requirements by default, so the same rules are applied to our bootloader dependency. The `^0.7.7` is a so-called [_caret requirement_], which means "version `0.7.7` or a later compatible version". So if we find a bug and publish version `0.7.8` or `0.7.9`, cargo would automatically use the latest version, as long as it is still a version `0.7.x`. However, it wouldn't choose version `0.8.0`, because it is not considered as compatible. Note that dependencies in your `Cargo.toml` are caret requirements by default, so the same rules are applied to our bootloader dependency.
[_caret requirement_]: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#caret-requirements [_caret requirement_]: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#caret-requirements

View File

@@ -47,11 +47,11 @@ To implement the approach, we will need support from the bootloader, so we'll co
### Dependency Updates ### Dependency Updates
This post requires version 0.6.4 or later of the `bootloader` dependency and version 0.6.0 or later of the `x86_64` dependency. You can update the dependencies in your `Cargo.toml`: This post requires version 0.8.0 or later of the `bootloader` dependency and version 0.6.0 or later of the `x86_64` dependency. You can update the dependencies in your `Cargo.toml`:
```toml ```toml
[dependencies] [dependencies]
bootloader = "0.6.4" bootloader = "0.8.0"
x86_64 = "0.6.0" x86_64 = "0.6.0"
``` ```
@@ -305,7 +305,7 @@ We choose the first approach for our kernel since it is simple, platform-indepen
```toml ```toml
[dependencies] [dependencies]
bootloader = { version = "0.6.4", features = ["map_physical_memory"]} bootloader = { version = "0.8.0", 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. 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.