You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, accessing any of the fundamental UEFI tables is very annoying and sometimes leads to annoying lifetime issues.
Apps either have to resort to passing a st/bs/rt reference around everywhere or have to resort to the un-ergonomic (because it's unsafe and doesn't even return a proper reference) system_table() from uefi-services. The former isn't even viable if implementing an API/protocol with fixed function signatures.
There are two things to note:
BootServices/RuntimeServices are really just a list of global functions. The only reason they are provided through SystemTable is because UEFI isn't a hosted environment with dynamic linking.
No functions in them take a this pointer.
I propose the API to be changed such that:
The application's entry-point is changed to a simple fn main() -> Result signature. The #[entry] (which I would prefer renamed to efi_main) provides the real entry-point internally, stores the SystemTable and image handle somewhere, and calls into the marked main function. On return, it does the right thing(tm) with the Result (print out a message and return status code).
All functions in BootServices/RuntimeServices are changed to associated functions that access the global table pointer internally. As they don't take a this pointer, they are just global functions as is basically done in EDK2 (well, they provide a global pointer to the table struct, same difference). It's more ergonomic and will eliminate some annoying lifetime issues. It also obviates the need for some structs like ScopedProtocol to keep a ref to the table.
To protect against use after exiting boot services, the BootServices table pointer can be replaced by the exit handler with a None or replaced with a custom implementation that panics if actually used.
Access to stdin/stdout/stderr should be provided via associated functions from the Input/Output types (and panic after boot services exit).
An associated function would be provided to get direct access to the tables if needed.
This would also remove the need for a View on SystemTable: any members that go away should be Options and set to None once boot services are exited by the exit handler. (In fact, the UEFI spec recommends doing so.)
The text was updated successfully, but these errors were encountered:
Right now, accessing any of the fundamental UEFI tables is very annoying and sometimes leads to annoying lifetime issues.
Apps either have to resort to passing a
st
/bs
/rt
reference around everywhere or have to resort to the un-ergonomic (because it's unsafe and doesn't even return a proper reference)system_table()
from uefi-services. The former isn't even viable if implementing an API/protocol with fixed function signatures.There are two things to note:
BootServices
/RuntimeServices
are really just a list of global functions. The only reason they are provided throughSystemTable
is because UEFI isn't a hosted environment with dynamic linking.this
pointer.I propose the API to be changed such that:
fn main() -> Result
signature. The#[entry]
(which I would prefer renamed toefi_main
) provides the real entry-point internally, stores theSystemTable
and image handle somewhere, and calls into the marked main function. On return, it does the right thing(tm) with theResult
(print out a message and return status code).BootServices
/RuntimeServices
are changed to associated functions that access the global table pointer internally. As they don't take athis
pointer, they are just global functions as is basically done in EDK2 (well, they provide a global pointer to the table struct, same difference). It's more ergonomic and will eliminate some annoying lifetime issues. It also obviates the need for some structs likeScopedProtocol
to keep a ref to the table.BootServices
table pointer can be replaced by the exit handler with aNone
or replaced with a custom implementation that panics if actually used.Input/Output
types (and panic after boot services exit).View
onSystemTable
: any members that go away should beOption
s and set toNone
once boot services are exited by the exit handler. (In fact, the UEFI spec recommends doing so.)The text was updated successfully, but these errors were encountered: