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

Link to Github instead of gists

Browse Source
This commit is contained in:
Philipp Oppermann
2018-07-14 14:34:21 +02:00
parent 0f07341dea
commit 934c7f3413
2 changed files with 3 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
blog/content/second-edition/posts/06-cpu-exceptions/index.md
View File

@@ -431,9 +431,7 @@ extern "x86-interrupt" fn breakpoint_handler(_: &mut ExceptionStackFrame) {
// […] // […]
``` ```
For space reasons we don't show the full content here. You can find the full file [in this gist]. For space reasons we don't show the full content here. You can find the full file [on Github](https://github.com/phil-opp/blog_os/blob/master/src/bin/test-exception-breakpoint.rs).
[in this gist]: https://gist.github.com/phil-opp/ff80a6bfdfcc0e2e90bf3e566c58e3cf
It is basically a copy of our `main.rs` with some modifications to `_start` and `breakpoint_handler`. The most interesting part is the `BREAKPOINT_HANDLER_CALLER` static. It is an [`AtomicUsize`], an integer type that can be safely concurrently modifies because all of its operations are atomic. We increment it when the `breakpoint_handler` is called and verify in our `_start` function that the handler was called exactly once. It is basically a copy of our `main.rs` with some modifications to `_start` and `breakpoint_handler`. The most interesting part is the `BREAKPOINT_HANDLER_CALLER` static. It is an [`AtomicUsize`], an integer type that can be safely concurrently modifies because all of its operations are atomic. We increment it when the `breakpoint_handler` is called and verify in our `_start` function that the handler was called exactly once.

4
blog/content/second-edition/posts/07-double-faults/index.md
View File

@@ -404,9 +404,9 @@ That's it! Now the CPU should switch to the double fault stack whenever a double
From now on we should never see a triple fault again! From now on we should never see a triple fault again!
To ensure that we don't accidentally break the above, we should add a integration test for this. We don't show the code here for space reasons, but you can find it [in this gist][stack overflow test]. The idea is to do a `serial_println!("ok");` from the double fault handler to ensure that it is called. The rest of the file is is very similar to our `main.rs`. To ensure that we don't accidentally break the above, we should add a integration test for this. We don't show the code here for space reasons, but you can find it [on Github][stack overflow test]. The idea is to do a `serial_println!("ok");` from the double fault handler to ensure that it is called. The rest of the file is is very similar to our `main.rs`.
[stack overflow test]: https://gist.github.com/phil-opp/9600f367f10615219f3f22110a9a92eb [stack overflow test]: https://github.com/phil-opp/blog_os/blob/master/src/bin/test-exception-double-fault-stack-overflow.rs
## Summary ## Summary
In this post we learned what a double fault is and under which conditions it occurs. We added a basic double fault handler that prints an error message and added an integration test for it. In this post we learned what a double fault is and under which conditions it occurs. We added a basic double fault handler that prints an error message and added an integration test for it.