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
Copy file name to clipboardExpand all lines: library/std/src/sys/uefi/helpers.rs
+24-13
Original file line number
Diff line number
Diff line change
@@ -1,16 +1,25 @@
1
1
//! Contains most of the shared UEFI specific stuff. Some of this might be moved to `std::os::uefi`
2
2
//! if needed but no point in adding extra public API when there is not Std support for UEFI in the
3
3
//! first place
4
+
//!
5
+
//! Some Nomenclature
6
+
//! * Protocol:
7
+
//! - Protocols serve to enable communication between separately built modules, including drivers.
8
+
//! - Every protocol has a GUID associated with it. The GUID serves as the name for the protocol.
9
+
//! - Protocols are produced and consumed.
10
+
//! - More information about protocols can be found [here](https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide/3_foundation/36_protocols_and_handles)
4
11
5
12
use r_efi::efi::Guid;
6
13
7
14
usecrate::io::{self, const_io_error};
8
-
usecrate::mem::MaybeUninit;
15
+
usecrate::mem::{size_of,MaybeUninit};
9
16
usecrate::os::uefi;
10
17
usecrate::ptr::NonNull;
11
18
12
-
// Locate handles with a particular protocol GUID
19
+
/// Locate Handles with a particular Protocol GUID
13
20
/// Implemented using `EFI_BOOT_SERVICES.LocateHandles()`
21
+
///
22
+
/// Returns an array of [Handles](r_efi::efi::Handle) that support a specified protocol.
The current std has a few basic requirements to function:
255
-
1. Memory Allocation Services (`EFI_BOOT_SERVICES.AllocatePool()` and
256
-
`EFI_BOOT_SERVICES.FreePool()`) are available.
256
+
1. Memory Allocation Services (`EFI_BOOT_SERVICES.AllocatePool()` and `EFI_BOOT_SERVICES.FreePool()`) are available. This should be true in in the Driver Execution Environment or later.
257
257
If the above requirement is satisfied, the Rust code will reach `main`.
258
258
Now we will discuss what the different modules of std use in UEFI.
259
259
260
260
### Implemented features
261
261
#### alloc
262
262
- Implemented using `EFI_BOOT_SERVICES.AllocatePool()` and `EFI_BOOT_SERVICES.FreePool()`.
263
263
- Passes all the tests.
264
-
- Some Quirks:
265
-
- Currently uses `EfiLoaderData` as the `EFI_ALLOCATE_POOL->PoolType`.
264
+
- Currently uses `EfiLoaderData` as the `EFI_ALLOCATE_POOL->PoolType`.
266
265
#### cmath
267
266
- Provided by compiler-builtins.
268
267
#### env
269
-
- Just some global consants.
268
+
- Just some global constants.
270
269
#### locks
271
-
- Uses `unsupported/locks`.
272
-
- They should work for a platform without threads according to docs.
270
+
- The provided locks should work on all standard single-threaded UEFI implementations.
273
271
#### os_str
274
-
- Uses WTF-8 from windows.
272
+
- While the strings in UEFI should be valid UCS-2, in practice, many implementations just do not care and use UTF-16 strings.
273
+
- Thus, the current implementation supports full UTF-16 strings.
275
274
276
275
## Example: Hello World With std
277
-
The following code is a valid UEFI application showing stdio in UEFI. It also
278
-
uses `alloc` type `OsString` and `Vec`.
276
+
The following code features a valid UEFI application, including stdio and `alloc` (`OsString` and `Vec`):
279
277
280
278
This example can be compiled as binary crate via `cargo` using the toolchain
0 commit comments