Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Re-design SystemTable/BootServices/RuntimeServices #841

Closed
medhefgo opened this issue Jun 1, 2023 · 0 comments
Closed

RFC: Re-design SystemTable/BootServices/RuntimeServices #841

medhefgo opened this issue Jun 1, 2023 · 0 comments

Comments

@medhefgo
Copy link
Contributor

medhefgo commented Jun 1, 2023

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.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant