rust-osdev/uefi-rs

Tracking issue for use of unstable features

nicholasbishop opened this issue · 2 comments

nicholasbishop commented

The uefi and uefi-services crates currently uses a number of unstable features. Right now I don't think we can avoid unstable features, but eventually we want to be able to compile on stable Rust. I figure a good thing to do in support of that goal is to track what unstable features we use, the status of those features, and why we need them. (This list will likely change over time, I'll try to keep this issue up to date.)

Note: I'm not including the unstable -Zbuild-std feature in this issue, as that's a cargo feature. It's also not a hard requirement for a couple reasons:

  • The uefi crate doesn't have to be built for one of the UEFI targets, e.g. it can be used from within an ELF kernel that was booted on a UEFI device.
  • If you are building for a UEFI target, it doesn't necessarily have to be done with -Zbuild-std. You can build a stable Rust compiler with support for the UEFI targets, they just aren't available as prebuilts with rustup because they are tier 3 platforms.
  • Update: -Zbuild-std is no longer required as the three UEFI targets are now tier 2 and available via rustup.

What features are used

Why do we need these features?

These features fall into three categories:

  • Required (these are features we can't really do without):
    • abi_efiapi: When compiling for a UEFI target this is pretty much equivalent to using the C ABI, but specifying the EFI ABI is necessary when compiling for other targets.
    • alloc_error_handler: This is required when using the standard alloc crate without the std crate. There is a related default_alloc_error_handler which seems like it might be more likely to get stabilized.
  • Safety (we could potentially drop some of these features, but they help make the code safer, or to make unsafe code more readable):
    • maybe_uninit_slice: could probably be replaced with some unsafe casts. Dropped this feature in #622
    • negative_impls: this is used to mark implementors of Protocol as !Send and !Sync. The practical consequences of this seem pretty limited to me since prior to exiting boot services you're running on a single processor anyway, and there's no threading support. But I definitely haven't thought about this deeply, perhaps there's more to it. Dropped this feature in #607
    • ptr_metadata: makes the DST code cleaner, but could be replaced with some unsafe hacks. Dropped this feature in #621
    • vec_into_raw_parts: only used in one place, could probably be replaced by copying some code from the alloc lib. Dropped this feature in #622
  • Nice-to-have (we could drop these features without much loss of functionality):
    • try_trait_v2: This is used to make ? work with Status. Within the uefi crate this feature is actually barely used. Harder to say if users of the crate are making use of the feature, but I think it would probably be fine to drop it as it can generally be replaced with Result::from(status)?. Dropped this feature in #479

Next steps

I don't think there's much for us to do until abi_efiapi and alloc_error_handler (or default_alloc_error_handler) are stabilized, since as described above those seem pretty necessary to me for the functionality we want to expose from uefi and uefi-services.

We should continue to be judicious about enabling more unstable features, but for new features in the mold of maybe_uninit_slice that just make unsafe code more readable and are easy to replace with local polyfills I don't think there's much reason not to add them where useful.

Once those two required features are stabilized though, we might want to consider trying to more aggressively prune away remaining uses of unstable features so that the crates can compile on stable, possibly with some additional crate features to gate use of unstable features for users that remain on nightly.

nicholasbishop commented

Some status updates:

  • I've been working on resolving some of the remaining issues for the abi_efiapi feature. I'm hoping that we can propose that for stabilization soon.
  • The default_alloc_error_handler feature has been nominated for stabilization; once that's merged (plus 3 months for our MSRV bump) we should be able to drop our use of the alloc_error_handler feature.

If and when those stabilizations happen, I think we can start looking seriously at finding stable alternatives for the remaining four unstable features so that this crate can be used on stable Rust.

  • 🎉5
nicholasbishop commented

Status update:

All of the features we need have been stabilized as of the 2023-01-14 nightly. There are two remaining PRs to merge in uefi-rs (blocked for now since they require nightly MSRV bumps):

Rust 1.68 should have all the features we need, and according to https://forge.rust-lang.org that will become stable on March 9, 2023. We'll need to consider what our MSRV policy should be as we move from nightly to stable (keeping in mind that we still have some unstable feature use gated behind a feature flag).