diff --git a/content/this-month/2022-06/index.md b/content/this-month/2022-06/index.md new file mode 100644 index 00000000..f52db07b --- /dev/null +++ b/content/this-month/2022-06/index.md @@ -0,0 +1,182 @@ ++++ +title = "This Month in Rust OSDev: June 2022" +date = 2022-07-10 + +[extra] +month = "June 2022" +authors = [ + "phil-opp", + "phip1611", + # add yourself here +] ++++ + +Welcome to a new issue of _"This Month in Rust OSDev"_. In these posts, we give a regular overview of notable changes in the Rust operating system development ecosystem. + + + +This series is openly developed [on GitHub](https://github.com/rust-osdev/homepage/). Feel free to open pull requests there with content you would like to see in the next issue. If you find some issues on this page, please report them by [creating an issue](https://github.com/rust-osdev/homepage/issues/new) or using our [_comment form_](#comment-form) at the bottom of this page. + + + +## Project Updates + +In this section, we give an overview of notable changes to the projects hosted under the [`rust-osdev`] organization. + +[`rust-osdev`]: https://github.com/rust-osdev/about + +### [`linked-list-allocator`](https://github.com/rust-osdev/linked-list-allocator) + +Maintained by [@phil-opp](https://github.com/phil-opp) and [@jamesmunns](https://github.com/jamesmunns) + +The `linked-list-allocator` crate provides a basic `no_std` allocator that builds a linked list from freed memory blocks and thus needs no additional data structures. + +This month, [@jamesmunns](https://github.com/jamesmunns) redesigned the internal API for traversing the linked list in order to pass the strict tests of [`miri`](https://github.com/rust-lang/miri), which is an experimental interpreter for Rust's intermediate representation (MIR). Among other things, `miri` checks that pointers are correctly aligned and that no invalid aliasing occurs (based on different formal models). By checking our implementation against `miri`, we make it more robust and reduce the chance that undefined behavior occurs with future compiler versions. + +The change was implemented across the following pull requests: + +- [Refactor with Cursor-based API, and passing Miri tests](https://github.com/rust-osdev/linked-list-allocator/pull/62) (published as `v0.10.0`, but yanked later) +- ([fix(deallocate_middle): advance to next in `try_insert_after`](https://github.com/rust-osdev/linked-list-allocator/pull/63)) +- [Fix free logic](https://github.com/rust-osdev/linked-list-allocator/pull/64) ([published](https://github.com/rust-osdev/linked-list-allocator/pull/65) as `v0.10.1`) + +Thanks to [@jamesmunns](https://github.com/jamesmunns) for the redesign and [@haraldh](https://github.com/haraldh) for reporting a critical issue in the `v0.10.0` release and providing a fix! Also, we would like to welcome [@jamesmunns](https://github.com/jamesmunns) as a maintainer of this crate! + +### [`multiboot2`](https://github.com/rust-osdev/multiboot2) + +Maintained by [@IsaacWoods](https://github.com/IsaacWoods), [@phip1611](https://github.com/phip1611), [@robert-w-gries](https://github.com/robert-w-gries), [@ahmedcharles](https://github.com/ahmedcharles), and [@Caduser2020](https://github.com/Caduser2020) + +The `multiboot2` crate provides abstraction types for the multiboot information structure (MBI) +of multiboot2 bootloaders. The latest release of the `multiboot2`-crate is now `v.0.14.0` (was +`v0.13.2`). It contains some small breaking changes because so far, we used some unsafe code and +relied on having not to verify UTF-8 strings. For a full changelog, please refer to the +[GitHub repo](https://github.com/rust-osdev/multiboot2/blob/main/multiboot2/Changelog.md). + +### [`uefi-rs`](https://github.com/rust-osdev/uefi-rs) + +Maintained by [@GabrielMajeri](https://github.com/GabrielMajeri) and [@nicholasbishop](https://github.com/nicholasbishop) + +The `uefi` crate provides safe and performant wrappers for [UEFI](https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface), the successor to the BIOS. + +We merged the following changes in June: + +#### Fixes + +- [Remove `exts::allocate_buffer`](https://github.com/rust-osdev/uefi-rs/pull/443) +- [Fix incorrect pointer cast in get_rng](https://github.com/rust-osdev/uefi-rs/pull/447) + +#### Improvements + +- [Remove unused `From` impls](https://github.com/rust-osdev/uefi-rs/pull/450) +- [Remove `eh_personality` lang item](https://github.com/rust-osdev/uefi-rs/pull/451) +- [Simplify `uefi-services` panic handler](https://github.com/rust-osdev/uefi-rs/pull/453) + +#### Internal changes + +- [Fix `query_variable_info` test](https://github.com/rust-osdev/uefi-rs/pull/442) +- [Fix errors due to deprecations in the `clap` API](https://github.com/rust-osdev/uefi-rs/pull/445) + +### [`bootloader`](https://github.com/rust-osdev/bootloader) + +Maintained by [@phil-opp](https://github.com/phil-opp), [@rybot666](https://github.com/rybot666), and [@64](https://github.com/64) + +The `bootloader` crate implements a custom Rust-based bootloader for easy loading of 64-bit ELF executables. This month, we made more progress on the upcoming `v0.11` version: + +- [WIP: try to start loading FAT partition in second stage](https://github.com/rust-osdev/bootloader/commit/3b6aa00dc33005f4353568c5dccad694d0f54f90) +- [Start custom FAT implementation based on `mini_fat` crate](https://github.com/rust-osdev/bootloader/commit/abfdba522e990fcaf865302b7b7d91f0abef04a7) (to keep the executable size down) +- [Read root dir entries from FAT partition](https://github.com/rust-osdev/bootloader/commit/96d2bdbae6fdc91c8df958fd09d4207a3ab20020) +- [Use segment-based addressing for DAP to support loading larger second stages](https://github.com/rust-osdev/bootloader/commit/eef2109861d718e0da82b3c5e4c2d9308d34da56) +- [Implement looking up `kernel-x86_64` file on FAT partition](https://github.com/rust-osdev/bootloader/commit/1d7ff1f0627fa33dab3f811af150a547e1f48172) +- [Read FAT clusters of kernel file](https://github.com/rust-osdev/bootloader/commit/06d3b9521cc8bac981068bafe0ab84b5c4a7e8c0) +- [Ensure proper alignment of DAP target buffer](https://github.com/rust-osdev/bootloader/commit/6e8f9fa964bfcd23b95fe902fe3a5f2c55065e27) +- [Enter unreal mode](https://github.com/rust-osdev/bootloader/commit/7a24837692d96c8e9b04377fa2e7646648637dcb) + +### [`x86_64`](https://github.com/rust-osdev/x86_64) + +Maintained by [@phil-opp](https://github.com/phil-opp), [@josephlr](https://github.com/orgs/rust-osdev/people/josephlr), [@Freax13](https://github.com/orgs/rust-osdev/people/Freax13), and [@rybot666](https://github.com/orgs/rust-osdev/people/rybot666) + +The `x86_64` crate provides various abstractions for `x86_64` systems, including wrappers for CPU instructions, access to processor-specific registers, and abstraction types for architecture-specific structures such as page tables and descriptor tables. + +In June, we merged the following pull request: + +- [Add `registers::debug`](https://github.com/rust-osdev/x86_64/pull/286) ([published](https://github.com/rust-osdev/x86_64/pull/386) as `v0.14.10`) + +Thanks to [@mkroening](https://github.com/mkroening) for this contribution! + +### [`cargo-xbuild`](https://github.com/rust-osdev/cargo-xbuild) + +Maintained by [@phil-opp](https://github.com/phil-opp) + +The `cargo-xbuild` project provides `cargo` command wrappers to cross-compile the sysroot crates `core` and `alloc`. It is mostly useful in situations, where cargo's unstable `-Zbuild-std` flag is not usable. + +This month, we fixed a build error of the `alloc` crate on the latest nightlies: + +- [Fix: The alloc crate uses the Rust 2021 edition now](https://github.com/rust-osdev/cargo-xbuild/pull/105) (published as `v0.6.6`) + +## Call for Participation + +Want to contribute to a Rust OSDev project, but don't know where to start? Pick up one of these outstanding +issues in one of our projects and get started! + + + +- [(`rust-osdev/volatile`) New design based on pointer types](https://github.com/rust-osdev/volatile/pull/28) + + We are currently discussing a new design for the `volatile` crate based on raw pointer types in order to avoid potential undefined behavior. The linked pull requests proposes an implementation where the volatile wrapper type is `Copy` and its methods take `self` by value. We haven't reached a decision yet, so if anyone has more input on this, please join the discussion. For more context, see also [PR #22](https://github.com/rust-osdev/volatile/pull/22). + + + +If you maintain a Rust project related to operating system development and are looking for contributors, especially for tasks suited to people getting started in this space, please [create a PR](https://github.com/rust-osdev/homepage/pulls) against the `next` branch with the tasks you want to include in the next issue. + +## Other Projects + +In this section, we describe updates to Rust OS projects that are not directly related to the `rust-osdev` organization. Feel free to [create a pull request](https://github.com/rust-osdev/homepage/pulls) with the updates of your OS project for the next post. + +### [`google/gpt-disk-rs`](https://github.com/google/gpt-disk-rs) + +(Section written by [@nicholasbishop](https://github.com/nicholasbishop)) + +`gpt-disk-rs` is a collection of three libraries related to [GPT](https://en.wikipedia.org/wiki/GUID_Partition_Table) (GUID Partition Table) disk data. The crates are no-std by default, have minimal dependencies, and include a lot of documentation. I'm hoping they'll be a suitable base for any project that wants to read or write GPT data. + +* [`uguid`](https://crates.io/crates/uguid): GUID data type. +* [`gpt_disk_types`](https://crates.io/crates/gpt_disk_types): all the GPT types defined by the UEFI specification +* [`gpt_disk_io`](https://crates.io/crates/gpt_disk_io): types for reading and writing GPT data to an abstract block IO device. + +### [`vinc/moros`](https://github.com/vinc/moros) + +(Section written by [@vinc](https://github.com/vinc)) + +MOROS is a text-based hobby operating system targeting computers with a x86-64 architecture and a BIOS. It is inspired by Unix and ITS but is closer to a modern DOS at the moment in term of features. + +In the last month I finally managed to run rust programs (without alloc) inside the OS after being limited to nasm programs for a long time. This triggered a lot of refactoring and improvements in the shell and the lisp language used for scripting. + +Next step will be publishing a 0.8.0 release and working on userspace allocation. + +### [`phil-opp/blog_os`](https://github.com/phil-opp/blog_os) + +(Section written by [@phil-opp](https://github.com/phil-opp)) + +This month, we merged the following improvements: + +- [[Translation][Korean] post-03 (edition-2)](https://github.com/phil-opp/blog_os/pull/1121) + - Thanks to [@JOE1994](https://github.com/JOE1994) for creating the translation and [@QuqqU](https://github.com/QuqqU) for reviewing it! +- [Fix typo in Japanese translation](https://github.com/phil-opp/blog_os/pull/1122) (thanks to [@KisaragiEffective](https://github.com/KisaragiEffective)) +- [Translate the giscus comment system](https://github.com/phil-opp/blog_os/pull/1118) +- [Move comment threads for translated posts to separate category](https://github.com/phil-opp/blog_os/pull/1116) +- [Remove goatcounter analytics again](https://github.com/phil-opp/blog_os/pull/1117) + +## Join Us? + +Are you interested in Rust-based operating system development? Our `rust-osdev` organization is always open to new members and new projects. Just let us know if you want to join! A good way for getting in touch is our [gitter channel](https://gitter.im/rust-osdev/Lobby). diff --git a/static/css/main.css b/static/css/main.css index 49a46338..7afc2f93 100644 --- a/static/css/main.css +++ b/static/css/main.css @@ -41,6 +41,7 @@ h1 code, h2 code, h3 code, h4 code, h5 code, h6 code { } .maintainers { + border-top: 1px solid #ddd; display: block; margin-top: -.5rem; color: #9a9a9a;