Skip to content

Commit e3b1c6d

Browse files
phip1611phip1611
committed
XXX 2024-08: uefi v0.30 significant changes
1 parent aadeea3 commit e3b1c6d

File tree

1 file changed

+163
-0
lines changed

1 file changed

+163
-0
lines changed

‎content/this-month/2024-08/index.md‎

Lines changed: 163 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,163 @@
1+
+++
2+
title = "This Month in Rust OSDev: July 2024"
3+
date = 2024-08-03
4+
5+
[extra]
6+
month = "July 2024"
7+
editors = ["phil-opp"]
8+
+++
9+
10+
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.
11+
12+
<!-- more -->
13+
14+
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 <a href="#comment-form">_comment form_</a> at the bottom of this page.
15+
16+
<!--
17+
This is a draft for the upcoming "This Month in Rust OSDev (July 2024)" post.
18+
Feel free to create pull requests against the `next` branch to add your
19+
content here.
20+
Please take a look at the past posts on https://rust-osdev.com/ to see the
21+
general structure of these posts.
22+
-->
23+
24+
## Announcements, News, and Blog Posts
25+
26+
Here we collect news, blog posts, etc. related to OS development in Rust.
27+
28+
<!--
29+
Please follow this template:
30+
31+
- [Title](https://example.com)
32+
- (optional) Some additional context
33+
-->
34+
35+
36+
## Infrastructure and Tooling
37+
38+
In this section, we collect recent updates to `rustc`, `cargo`, and other tooling that are relevant to Rust OS development.
39+
40+
<!--
41+
Please use the following template:
42+
43+
- [Title](https://example.com)
44+
- (optional) Some additional context
45+
-->
46+
47+
48+
## `rust-osdev` Projects
49+
50+
In this section, we give an overview of notable changes to the projects hosted under the [`rust-osdev`](https://github.com/rust-osdev/about) organization.
51+
52+
<!--
53+
Please use the following template:
54+
55+
### [`repo_name`](https://github.com/rust-osdev/repo_name)
56+
<span class="maintainers">Maintained by [@maintainer_1](https://github.com/maintainer_1)</span>
57+
58+
The `repo_name` crate ...<<short introduction>>...
59+
60+
We merged the following changes this month:
61+
<<changelog, either in list or text form>>
62+
-->
63+
64+
### [`uefi-rs`](https://github.com/rust-osdev/uefi-rs)
65+
<span class="maintainers">Maintained by [@GabrielMajeri](https://github.com/GabrielMajeri), [@nicholasbishop](https://github.com/nicholasbishop), and [@phip1611](https://github.com/phip1611)</span>
66+
67+
The `uefi-rs` crate provides safe and performant wrappers for [UEFI](https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface), the successor to the BIOS.
68+
Recently, we deprecated the [`uefi-services`] crate and removed all usages from
69+
the [`uefi`](https://github.com/rust-osdev/uefi-rs) repository. A new drop-in
70+
replacement exists in [`uefi::helpers`](https://docs.rs/uefi/latest/uefi/helpers/index.html).
71+
72+
Recently, we released version `v0.30` with some notable changes.
73+
74+
#### Memory Map Refactoring
75+
76+
TL;DR: What used to return `MemoryMap<'buf>` in the API, now returns
77+
`MemoryMapOwned`. Additionally, you can parse a chunk of memory using
78+
`MemoryMapRef` or `MemoryMapRefMut`.
79+
80+
We put significant effort into refactoring our abstractions for the UEFI memory
81+
map. These started in release v0.29 and were finalized in release v0.30.
82+
Instead of one `MemoryMap<'buf>` type, we now have the traits `MemoryMap` and
83+
`MemoryMapMut` along with the implementations `MemoryMapRef`, `MemoryMapRefMut`,
84+
and `MemoryMapOwned`. It is recommended to work with the specific
85+
implementations, as the main purpose for the traits is only to enforce a
86+
consistent API for these three implementations. This gives users the
87+
flexibility to cover all possible use cases one can have with an UEFI memory
88+
map. Read more:
89+
- [#1175](https://github.com/rust-osdev/uefi-rs/pull/1175)
90+
- [#1251](https://github.com/rust-osdev/uefi-rs/pull/1251)
91+
- [#1240](https://github.com/rust-osdev/uefi-rs/pull/1240)
92+
- [#1263](https://github.com/rust-osdev/uefi-rs/pull/1263)
93+
94+
In any case, obtaining the memory map from UEFI is hidden behind the
95+
public API of the crate, but we made it very easy to read/parse it in all
96+
possible scenarios!
97+
98+
### Outlook: Freestanding Functions API Change
99+
100+
On the long term, we are planning a massive API change. The typical use-case
101+
of our library users is to write EFI image with code leveraging boot services
102+
and exiting them before handing over to the next step (typically load an ELF
103+
kernel). These EFI images typically are "99% code" using boot services, until
104+
they are exited and control is handed over.
105+
106+
Although the exiting API design ensures via the type system that no boot
107+
service scan be called after they have been exited, the test of time has proven
108+
that this adds unjustified complexity without bringing much value add.
109+
110+
Instead, with the new API, which we provide **additionally** at this point,
111+
one can use freestanding functions which are behind the new modules:
112+
113+
- `uefi::system`: is a new module that provides freestanding functions for
114+
accessing fields of the global system table.
115+
- `uefi::boot`:
116+
is a new module that provides freestanding functions for boot services using
117+
the global system table.
118+
- `uefi::runtime`: is a new module that provides freestanding functions for
119+
runtime services using the global system table.
120+
121+
This solves API inconsistencies and restrictions already existing so far, and
122+
makes the overall handling a lot easier. This comes with the costs that
123+
functions may panic, if the boot services were exited but one tries to use
124+
them. However, the massive API simplification justifies this.
125+
126+
The work has just been started. Follow the progress and discussions on
127+
[GitHub](https://github.com/rust-osdev/uefi-rs/issues/893#issuecomment-2241610633).
128+
129+
### Other
130+
131+
There were also a ton of other interesting fixes, changes, and additions!
132+
Check out our [Changelog](https://github.com/rust-osdev/uefi-rs/blob/main/uefi/CHANGELOG.md).
133+
134+
We merged the following PRs this month:
135+
<!-- todo -->
136+
137+
138+
## Other Projects
139+
140+
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.
141+
142+
<!--
143+
Please use the following template:
144+
145+
### [`owner_name/repo_name`](https://github.com/rust-osdev/owner_name/repo_name)
146+
<span class="maintainers">(Section written by [@your_github_name](https://github.com/your_github_name))</span>
147+
148+
...<<your project updates>>...
149+
-->
150+
151+
### [`phip1611/bit_ops`](https://github.com/phip1611/bit_ops)
152+
<span class="maintainers">(Section written by [@phip1611](https://github.com/phip1611))</span>
153+
154+
I've recently created and published [`bit_ops`](https://github.com/phip1611/bit_ops).
155+
It offers common bit-oriented operations on primitive integer types with a focus on
156+
`no_std` and `const` compatibility. Unlike other crates that provide tooling to
157+
create sophisticated high-level types with bitfields, the focus of `bit_ops` is
158+
on raw primitive integer types.
159+
160+
161+
## Join Us?
162+
163+
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 [Zulip chat](https://rust-osdev.zulipchat.com).

0 commit comments

Comments
 (0)