RFC: Add a uefi-raw crate

[nicholasbishop]

I'd like to propose adding a uefi-raw crate that will mostly contain type definitions that closely match types in the UEFI spec. All fields in these types will be public, and there will be few relatively few impls. (For example, there might be some Debug/Display impls, but not methods that wrap all the extern "efiapi" function pointers like uefi provides).

The new crate will be useful for projects that want to implement UEFI services, as opposed to just using them. My motivation for this is #715; having access to all the private fields is necessary for implementing Miri stubs. But it would also be useful for someone who wanted to implement a real UEFI environment, or part of one (e.g. I think uboot provides a partial UEFI boot services implementation, that sort of thing.)

We can add a static checker to xtask to make guarantees about the new crate, e.g. verifying that only FFI-compat types are used, being consistent about using raw pointers instead of references, making sure all fn pointers are marked extern efiapi, that sort of thing.

We'll add uefi-raw as a dependency of uefi, and use the uefi-raw types to implement the safe interface. So for example the definition of BootServices in uefi-raw would contain all the function pointers, and the definition of BootServices in uefi would look like

#[repr(transparent)]
pub struct BootServices(uefi_raw::BootServices);

In general we will not publically expose types from uefi-raw in uefi, except where the type doesn't need any additional level of safety wrapping. For example, the various newtype_enum! types can be safely re-exported without any additional wrapper.

The reason for uefi-raw being in a separate crate, as opposed to just a uefi::raw module, is the documentation. We don't want all search terms to come up with two results for everything.

Actually implementing the crate can be done incrementally. Once we have the basic framework in place we can transfer over internal struct implementations piece by piece.

[phip1611]

I like the idea and fully support it without additional comments. Sounds very sensible what you've written down. Nice!

PS: Would uefi-sys be more compliant with the ecosystem?

[nicholasbishop]

PS: Would uefi-sys be more compliant with the ecosystem?

That was my thought initially as well, but as far as I've seen -sys crates actually link to a C library and expose a Rust interface. This crate is slightly different since it's wrapping a specification and not linking to any C library. It probably doesn't matter much either way, but I figured a slightly different convention of -raw might make sense to distinguish it.

[phip1611]

This can be closed, right? We have the new crate now