From 2d61a463fcaf4181d6d57d95582c8f55a4e85ce5 Mon Sep 17 00:00:00 2001 From: Philipp Oppermann Date: Fri, 26 Apr 2019 12:07:31 +0200 Subject: [PATCH] Use the entry point macro for lib.rs too --- .../posts/09-paging-implementation/index.md | 25 ++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/blog/content/second-edition/posts/09-paging-implementation/index.md b/blog/content/second-edition/posts/09-paging-implementation/index.md index d728a8c3..fab854b4 100644 --- a/blog/content/second-edition/posts/09-paging-implementation/index.md +++ b/blog/content/second-edition/posts/09-paging-implementation/index.md @@ -359,9 +359,32 @@ fn kernel_main(boot_info: &'static BootInfo) -> ! { We no longer need to use `extern "C"` or `no_mangle` for our entry point, as the macro defines the real lower level `_start` entry point for us. The `kernel_main` function is now a completely normal Rust function, so we can choose an arbitrary name for it. The important thing is that it is type-checked so that a compilation error occurs when we use a wrong function signature, for example by adding an argument or changing the argument type. +Let's perform the same change in our `lib.rs`: + +```rust +// in src/lib.rs + +#[cfg(test)] +use bootloader::{entry_point, BootInfo}; + +#[cfg(test)] +entry_point!(test_kernel_main); + +/// Entry point for `cargo xtest` +#[cfg(test)] +fn test_kernel_main(_boot_info: &'static BootInfo) -> ! { + // like before + init(); + test_main(); + hlt_loop(); +} +``` + +Since the entry point is only used in test mode, we add the `#[cfg(test)]` attribute to all items. We give our test entry point the distinct name `test_kernel_main` to avoid confusion with the `kernel_main` of our `main.rs`. We don't use the `BootInfo` parameter for now, so we prefix the parameter name with a `_` to silence the unused variable warning. + ## Implementation -Now that we have access to physical memory, we can finally start our implementation. First, we will take a look at the currently active page tables that our kernel runs on. In the second step, we will create a translation function that returns the physical address that a given virtual address is mapped to. As the last step, we will try to modify the page tables in order to create a new mapping. +Now that we have access to physical memory, we can finally start to implement our page table code. First, we will take a look at the currently active page tables that our kernel runs on. In the second step, we will create a translation function that returns the physical address that a given virtual address is mapped to. As the last step, we will try to modify the page tables in order to create a new mapping. Before we begin, we create a new `memory` module for our code: