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

Remove old “Update” sections (#244)

Browse Source 
Most of these updates are quite old and thus distracting. Instead, we now have a “Recent Changes” box in the sidebar of the front page.
This commit is contained in:
Philipp Oppermann
2016-10-15 17:10:43 +02:00
committed by GitHub
parent 941fca8b0d
commit 92b04dfba7
5 changed files with 0 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
blog/post/02-entering-longmode.md
View File

@@ -23,9 +23,6 @@ I tried to explain everything in detail and to keep the code as simple as possib
[create an issue]: https://github.com/phil-opp/blog_os/issues [create an issue]: https://github.com/phil-opp/blog_os/issues
[source code]: https://github.com/phil-opp/blog_os/tree/entering_longmode/src/arch/x86_64 [source code]: https://github.com/phil-opp/blog_os/tree/entering_longmode/src/arch/x86_64
_Notable Changes_: We don't use 1GiB pages anymore, since they have [compatibility problems][1GiB page problems]. The identity mapping is now done through 2MiB pages.
[1GiB page problems]: https://github.com/phil-opp/blog_os/issues/17
## Some Tests ## Some Tests
To avoid bugs and strange errors on old CPUs we should check if the processor supports every needed feature. If not, the kernel should abort and display an error message. To handle errors easily, we create an error procedure in `boot.asm`. It prints a rudimentary `ERR: X` message, where X is an error code letter, and hangs: To avoid bugs and strange errors on old CPUs we should check if the processor supports every needed feature. If not, the kernel should abort and display an error message. To handle errors easily, we create an error procedure in `boot.asm`. It prints a rudimentary `ERR: X` message, where X is an error code letter, and hangs:

2
blog/post/03-set-up-rust.md
View File

@@ -22,8 +22,6 @@ This blog post tries to set up Rust step-by-step and point out the different pro
[file an issue]: https://github.com/phil-opp/blog_os/issues [file an issue]: https://github.com/phil-opp/blog_os/issues
[Github repository]: https://github.com/phil-opp/blog_os/tree/set_up_rust [Github repository]: https://github.com/phil-opp/blog_os/tree/set_up_rust
**Update**: We now use the `panic=abort` cargo option instead of `-Z no-landing-pads`. See [#170](https://github.com/phil-opp/blog_os/pull/170).
## Installing Rust ## Installing Rust
We need a nightly compiler, as we will use many unstable features. To manage Rust installations I highly recommend [rustup]. It allows you to install nightly, beta, and stable compilers side-by-side and makes it easy to update them. To use a nightly compiler for the current directory, you can run `rustup override add nightly`. We need a nightly compiler, as we will use many unstable features. To manage Rust installations I highly recommend [rustup]. It allows you to install nightly, beta, and stable compilers side-by-side and makes it easy to update them. To use a nightly compiler for the current directory, you can run `rustup override add nightly`.

3
blog/post/05-allocating-frames.md
View File

@@ -227,9 +227,6 @@ pub struct Frame {
``` ```
(Don't forget to add the `mod memory` line to `src/lib.rs`.) Instead of e.g. the start address, we just store the frame number. We use `usize` here since the number of frames depends on the memory size. The long `derive` line makes frames printable and comparable. (Don't forget to add the `mod memory` line to `src/lib.rs`.) Instead of e.g. the start address, we just store the frame number. We use `usize` here since the number of frames depends on the memory size. The long `derive` line makes frames printable and comparable.
_Update_: In a previous version, the `Clone` and `Copy` traits were derived, too. [This was removed][PR 52] to make the allocator interface safer.
[PR 52]: https://github.com/phil-opp/blog_os/pull/52
To make it easy to get the corresponding frame for a physical address, we add a `containing_address` method: To make it easy to get the corresponding frame for a physical address, we add a `containing_address` method:
```rust ```rust

14
blog/post/07-remap-the-kernel.md
View File

@@ -12,20 +12,6 @@ As always, you can find the source code on [Github]. Don't hesitate to file issu
[Github]: https://github.com/phil-opp/blog_os/tree/remap_the_kernel [Github]: https://github.com/phil-opp/blog_os/tree/remap_the_kernel
_Updates_:
- The `AreaFrameAllocator` [was broken][areaframeallocator broken] after switching to a new table. To fix this, we added the [Fixing the Frame Allocator] section and updated the [linker script][linker script update]. For a complete set of changes see [#131] and [this diff][#131-changes].
- We [fixed a bug][#141] in iterating over a section's frames. Therefor we added a `Frame::range_inclusive` function and updated the [Remapping the Kernel section]. For a complete list of changes check out [this diff][#141-changes].
[areaframeallocator broken]: https://github.com/phil-opp/blog_os/issues/126
[Fixing the Frame Allocator]: #fixing-the-frame-allocator
[linker script update]: #page-align-sections
[#131]: https://github.com/phil-opp/blog_os/pull/131
[#131-changes]: https://github.com/phil-opp/blog_os/compare/75aa669cdbb427c7bf0485c68692d243065cd3e9...635f7d3f9dced752f84d429e1d51f5c2b29854e3
[#141]: https://github.com/phil-opp/blog_os/pull/141
[Remapping the Kernel section]: #remapping-the-kernel
[#141-changes]: https://github.com/phil-opp/blog_os/commit/03ed3ce9a0758bf0d14a13144892c731216e25c6
## Motivation ## Motivation
In the [previous post], we had a strange bug in the `unmap` function. Its reason was a silent stack overflow, which corrupted the page tables. Fortunately, our kernel stack is right above the page tables so that we noticed the overflow relatively quickly. This won't be the case when we add threads with new stacks in the future. Then a silent stack overflow could overwrite some data without us noticing. But eventually some completely unrelated function fails because a variable changed its value. In the [previous post], we had a strange bug in the `unmap` function. Its reason was a silent stack overflow, which corrupted the page tables. Fortunately, our kernel stack is right above the page tables so that we noticed the overflow relatively quickly. This won't be the case when we add threads with new stacks in the future. Then a silent stack overflow could overwrite some data without us noticing. But eventually some completely unrelated function fails because a variable changed its value.

4
blog/post/09-catching-exceptions.md
View File

@@ -13,10 +13,6 @@ As always, the complete source code is on [Github]. Please file [issues] for any
[Github]: https://github.com/phil-opp/blog_os/tree/catching_exceptions [Github]: https://github.com/phil-opp/blog_os/tree/catching_exceptions
[issues]: https://github.com/phil-opp/blog_os/issues [issues]: https://github.com/phil-opp/blog_os/issues
**Update**: Due to a subtle [stack alignment bug], we no longer catch page faults in this post. Instead, we catch divide-by-zero errors.
[stack alignment bug]: https://github.com/phil-opp/blog_os/issues/184
## Exceptions ## Exceptions
An exception signals that something is wrong with the current instruction. For example, the CPU issues an exception if the current instruction tries to divide by 0. When an exception occurs, the CPU interrupts its current work and immediately calls a specific exception handler function, depending on the exception type. An exception signals that something is wrong with the current instruction. For example, the CPU issues an exception if the current instruction tries to divide by 0. When an exception occurs, the CPU interrupts its current work and immediately calls a specific exception handler function, depending on the exception type.