mirror of
https://github.com/phil-opp/blog_os.git
synced 2025-12-16 14:27:49 +00:00
Use the entry point macro for lib.rs too
This commit is contained in:
@@ -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.
|
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
|
## 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:
|
Before we begin, we create a new `memory` module for our code:
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user