11# API migration: Deprecating SystemTable/BootServices/RuntimeServices
22
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.
78
89A short example:
910
@@ -26,16 +27,18 @@ are replacing, so in most cases migration should be as simple as updating
2627imports and calling the freestanding function instead of a method on
2728` SystemTable ` , ` BootServices ` , or ` RuntimeServices ` .
2829
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.
3532
3633If you run into any issues with this migration, please feel free to chat with us
3734on [ Zulip] or file an [ issue] .
3835
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+
3942## Reason for the change
4043
4144See [ issue #893 ] [ RFC ] for the discussion that lead to this change.
0 commit comments