Description
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.