UDudev4096·Sep 14, 2024Submission
420 points · Open discussionphil-opp
blog_os
HTML2016–2024
phil-opp / blog_os
blog_os
Writing an OS in Rust
4Distinct people
8Mentions
0Explicit recommenders
17.8KGitHub stars
What to know before exploring
What it is
Writing an OS in Rust
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year8 dated mentions
Observed mentions: 2016-04-12 20:27:06 UTC to 2024-09-14 15:19:50 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
8 sourcesBlogos – Writing an OS in Rust
2 points · Open discussion> I'll prepare an update to fix this.
Update in https://github.com/phil-opp/blog_os/pull/738 and https://github.com/phil-opp/blog_os/pull/739
In Allocator Designs> The overflow scenario should be treated the same as the out-of-memory scenario and also return null.
Good point! I'll prepare an update to fix this.
> It can do better, in `dealloc` you can use `ptr` and `layout` to check if the allocation is at the end of the allocated region. If it is, `bump.next` can be reduced by `layout.size()`. This is optimal for lifo/stack style allocation patterns.
You're right. I already created a PR [1] for this shortly after publishing the article, but it seems like I forgot to merge it. There should be now an additional "Fixing the Test?" section that talks about freeing the last allocation.
[1]: https://github.com/phil-opp/blog_os/pull/722
In Allocator DesignsPhill's blog series is the best there is for kernel Rust. Glad to see another installment!
Note that in Rust today we can only use standard collection with the global allocator. https://github.com/phil-opp/blog_os/blob/post-10/src/main.rs... in the blog post it is intialized, and there's nothing to prevent allocation earlier and that will fail.
But there is work in progress (first https://github.com/rust-lang/rust/pull/58457) that will allow using local allocators, removing the ambient authority that makes that failure possible. Note that this doesn't mean a runtime cost. One can pass around a zero-sized token that is completely erased.
In Writing an OS in Rust: Heap AllocationThanks for the feedback!
I chose recursive page tables because the underlying mapping is very simple as it only requires to map a single level 4 page table entry. Thus, the bootloader does not need to force any address space layout on the kernel. If the kernel wants to use a different mapping scheme, it can use the recursive page table to perform that mapping and then unmap a single entry to undo the recursive mapping.
That being said, I like your proposal to map the complete physical address space to some higher-half location. It would allow to introduce a simple `phys_to_virt` function, which completely avoids the bitwise operations required for recursive page tables. It would also make this blog post much easier, which is always a good thing.
The question is how we can support that approach in the `bootloader` and `x86_64` crates witho
Read the rest
ut breaking users who wish to continue using recursive paging. I opened an issue in the blog repository with some ideas: https://github.com/phil-opp/blog_os/issues/545
Thanks! Fixed in https://github.com/phil-opp/blog_os/commit/f423c068fec803725...
In Writing an OS in Rust: Introduction to PagingI don't have much experience with ARM… I'm trying my hands on a stm32 board at the moment and things are very different from x86 so far. If someone has ideas or suggestions, I would appreciate a comment at [1].
[1]: https://github.com/phil-opp/blog_os/issues/142
In Writing an OS in Rust: Kernel Heap