-
Notifications
You must be signed in to change notification settings - Fork 20
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
Add UEFI APIs in std::os::uefi
#87
Comments
Can you elaborate what Concretely, I don't think we want to expose public types from another crate without first wrapping them -- even something with an essentially identical API as the underlying implementation are wrapped; for example If they're wrapped or reimplemented, this ACP needs to cover their whole API, and defend their inclusion. Since they're just from the (Note that I still haven't reviewed the implementation in any depth) |
cc @dvdhrm The reason to provide these methods in std is that when using Rust std (where main has a default signature), there needs to be a way for application developers to get access to the
|
Exposing the
As I see it, the biggest issue is that UEFI does not allow access to the system-table except through your entry-point. This capability-based model conflicts with the global state expected by rust-std. Most of the rust standard-library just does not allow for a user-supplied context object (Maybe it does? I haven't found a nice way.). I think we also need to consider what happens to rust code linked into a UEFI C application. In this case the entry-point is provided by the C code, and the rust library/helper is just linked into the application. With your proposed solution, you would be unable to use On a closing note, with |
That should work fine. Incidentally, it might be possible just make it return
This is something I would like to allow as well. Basically, not generate the custom entry point if Incidentally, I already have a function to init the global SystemTable and SystemHandle in |
This seems fine to experiment with as an unstable API. (We're not sure if this is the API we want to stabilize, but for nightly it seems fine to experiment.) I personally would prefer to see these become wrapper newtypes, to make it harder to accidentally pass BootServices to something expecting SystemTable or vice versa. They don't have to be full structure definitions, just an opaque wrapper around For |
I think it would be a good idea to have the wrapper type. I am also thinking if I should convert all access to these types to use |
if other code can only modify that memory on the same thread as your code, then either use |
Well, the reason I was suggesting volatile is to avoid compiler caching. In C land, that would mean making the pointer volatile (I think?). |
Why do you need to avoid compiler caching? |
Well, it is possible for the SystemTable to be accessed (and sometimes be modified like the console handle pointers) by interrupts. So it is best to ensure that the compiler reloads the value from memory each time it is accessed by the program. I am not sure how much of a problem this actually is, but I remember hearing that I should use volatile somewhere. I am currently using thread locals since UEFI is single-threaded. |
Ah okay. In that case, you should probably use a single-threaded CriticalSection Mutex like https://docs.rs/cortex-m/latest/cortex_m/interrupt/struct.Mutex.html |
Implemented modules: 1. alloc 2. os_str 3. env 4. math Tracking Issue: rust-lang#100499 API Change Proposal: rust-lang/libs-team#87 This was originally part of rust-lang#100316. Since that PR was becoming too unwieldy and cluttered, and with suggestion from @dvdhrm, I have extracted a minimal std implementation to this PR. Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
Implemented modules: 1. alloc 2. os_str 3. env 4. math Tracking Issue: rust-lang#100499 API Change Proposal: rust-lang/libs-team#87 This was originally part of rust-lang#100316. Since that PR was becoming too unwieldy and cluttered, and with suggestion from @dvdhrm, I have extracted a minimal std implementation to this PR. Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
Implemented modules: 1. alloc 2. os_str 3. env 4. math Tracking Issue: rust-lang#100499 API Change Proposal: rust-lang/libs-team#87 This was originally part of rust-lang#100316. Since that PR was becoming too unwieldy and cluttered, and with suggestion from @dvdhrm, I have extracted a minimal std implementation to this PR. Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
…ngjubilee Add Minimal Std implementation for UEFI # Implemented modules: 1. alloc 2. os_str 3. env 4. math # Related Links Tracking Issue: rust-lang#100499 API Change Proposal: rust-lang/libs-team#87 # Additional Information This was originally part of rust-lang#100316. Since that PR was becoming too unwieldy and cluttered, and with suggestion from `@dvdhrm,` I have extracted a minimal std implementation to this PR. The example in `src/doc/rustc/src/platform-support/unknown-uefi.md` has been tested for `x86_64-unknown-uefi` and `i686-unknown-uefi` in OVMF. It would be great if someone more familiar with AARCH64 can help with testing for that target. Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
Add Minimal Std implementation for UEFI # Implemented modules: 1. alloc 2. os_str 3. env 4. math # Related Links Tracking Issue: rust-lang/rust#100499 API Change Proposal: rust-lang/libs-team#87 # Additional Information This was originally part of rust-lang/rust#100316. Since that PR was becoming too unwieldy and cluttered, and with suggestion from `@dvdhrm,` I have extracted a minimal std implementation to this PR. The example in `src/doc/rustc/src/platform-support/unknown-uefi.md` has been tested for `x86_64-unknown-uefi` and `i686-unknown-uefi` in OVMF. It would be great if someone more familiar with AARCH64 can help with testing for that target. Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
Proposal
Problem statement
Hello everyone. I have been working on adding Rust std support for UEFI as a part of Google Summer of Code 2022.
This is a proposal to add some UEFI-specific APIs under
std::os::uefi
. It is related to PR.Motivation, use-cases
In the UEFI environment, most of the services/functionality is accessed using System Table, which is passed to the application at its entry. These APIs basically add ways to access the System Table and some of its most common members.
APIs to add
APIs I propose to add under
std::os::uefi::env
:pub fn get_system_table() -> NonNull<c_void>
pub fn get_system_handle() -> NonNull<c_void>
pub fn init_globals(handle: NonNull<c_void>, system_table: NonNull<c_void>)
APIs I propose to add under
std::os::uefi::ffi
(Just re-exportstd::os::windows::ffi
)OsStrExt
OsStringExt
Links and related work
The text was updated successfully, but these errors were encountered: