|
7 | 7 | //! important UEFI concepts. For more details of UEFI, see the latest [UEFI
|
8 | 8 | //! Specification][spec].
|
9 | 9 | //!
|
10 |
| -//! # Interaction with uefi services |
11 |
| -//! |
12 |
| -//! With this crate you can write code for the pre- and post-exit boot services |
13 |
| -//! epochs. However, the `uefi` crate unfolds its true potential when |
14 |
| -//! interacting with UEFI boot services. |
| 10 | +//! # Value-add and Use Cases |
| 11 | +//! |
| 12 | +//! With `uefi`, you have the flexibility to integrate selected types and |
| 13 | +//! abstractions into your project or to conveniently create EFI images, |
| 14 | +//! addressing the entire spectrum of your development needs. It supports you |
| 15 | +//! to write code for both pre- and post-exit boot services epochs. However, its |
| 16 | +//! true strength shines when you create EFI images that heavily interact with |
| 17 | +//! UEFI boot services. |
| 18 | +//! |
| 19 | +//! ## Example Use Cases |
| 20 | +//! |
| 21 | +//! This library significantly simplifies the process of creating **EFI images** |
| 22 | +//! by abstracting away much of the UEFI API complexity and by providing |
| 23 | +//! convenient wrappers. When we mention EFI images, we are talking about EFI |
| 24 | +//! applications, EFI boot service drivers, and EFI runtime service drivers, |
| 25 | +//! which typically have the `.efi` file extension. For instance, an EFI |
| 26 | +//! application could be an OS-specific loader, similar to _GRUB_ or _Limine_. |
| 27 | +//! |
| 28 | +//! Additionally, you can use this crate in non-EFI images (such as a kernel |
| 29 | +//! in ELF format) to perform tasks like parsing the UEFI memory map embedded in |
| 30 | +//! the boot information provided by a bootloader. It also enables access to |
| 31 | +//! UEFI runtime services from a non-EFI image kernel. |
15 | 32 | //!
|
16 | 33 | //! # Supported Architectures
|
17 | 34 | //!
|
|
0 commit comments