1
1
# API migration: Deprecating SystemTable/BootServices/RuntimeServices
2
2
3
- Starting in uefi-0.31.0, a significant API change has been introduced. We are
4
- transitioning away from modeling UEFI tables with structs, and instead providing
5
- an API based on freestanding functions. These functions make use of a global
6
- system table pointer that is set automatically by the ` entry ` macro.
3
+ We are in the process of introducing a significant API change in the ` uefi `
4
+ crate. We are transitioning away from modeling UEFI tables with structs, and
5
+ instead providing an API based on freestanding functions. These functions make
6
+ use of a global system table pointer that is set automatically by the ` entry `
7
+ macro.
7
8
8
9
A short example:
9
10
@@ -26,16 +27,18 @@ are replacing, so in most cases migration should be as simple as updating
26
27
imports and calling the freestanding function instead of a method on
27
28
` SystemTable ` , ` BootServices ` , or ` RuntimeServices ` .
28
29
29
- As of uefi-0.31.0, a few places in the API still require a reference to
30
- ` BootServices ` . You can retrieve one by calling
31
- ` uefi::table::system_table_boot().boot_services() ` .
32
-
33
- In uefi-0.31.0, the old API has been deprecated, but can still be used. It will
34
- be fully removed in a later release.
30
+ You can retrieve a global ` SystemTable ` with ` uefi::table::system_table_boot ` or
31
+ ` uefi::table::system_table_runtime ` to help ease the transition.
35
32
36
33
If you run into any issues with this migration, please feel free to chat with us
37
34
on [ Zulip] or file an [ issue] .
38
35
36
+ ## Timeline
37
+
38
+ As of uefi-0.31, the new API has been introduced alongside the old struct-based
39
+ API. We plan to deprecate the old API in the release after that, and then fully
40
+ remove the old API in a later release.
41
+
39
42
## Reason for the change
40
43
41
44
See [ issue #893 ] [ RFC ] for the discussion that lead to this change.
0 commit comments