|
1 | 1 | //! Rusty wrapper for the [Unified Extensible Firmware Interface][UEFI].
|
2 | 2 | //!
|
3 |
| -//! See the [Rust UEFI Book] for a tutorial, how-tos, and overviews of some |
4 |
| -//! important UEFI concepts. For more details of UEFI, see the latest [UEFI |
5 |
| -//! Specification][spec]. |
| 3 | +//! # TL;DR |
6 | 4 | //!
|
7 |
| -//! Feel free to file bug reports and questions in our [issue tracker], and [PR |
8 |
| -//! contributions][contributing] are also welcome! |
| 5 | +//! Develop Rust software that leverages **safe**, **convenient**, and |
| 6 | +//! **performant** abstractions for [UEFI] functionality. |
| 7 | +//! |
| 8 | +//! # About |
| 9 | +//! |
| 10 | +//! With `uefi`, you have the flexibility to just integrate selected types and |
| 11 | +//! abstractions into your project or to effortlessly create complete EFI |
| 12 | +//! images, addressing the entire spectrum of your development needs. |
| 13 | +//! |
| 14 | +//! `uefi` works with stable Rust, but additional nightly-only features are |
| 15 | +//! gated behind an `unstable` Cargo feature flag. |
9 | 16 | //!
|
10 |
| -//! # Interaction with uefi services |
| 17 | +//! ## Example Use Cases |
11 | 18 | //!
|
12 | 19 | //! 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. |
| 20 | +//! epochs. However, the `uefi` crate unfolds its true potential when crafting |
| 21 | +//! EFI images interacting with UEFI boot services and eventually exiting them. |
| 22 | +//! |
| 23 | +//! By EFI images (`image.efi`), we are referring to EFI applications, EFI |
| 24 | +//! boot service drivers, and EFI runtime service drivers. An EFI application |
| 25 | +//! might be your OS-specific loader technically similar to _GRUB_ or _Limine_. |
| 26 | +//! |
| 27 | +//! You can also use this crate to parse the UEFI memory map when a bootloader, |
| 28 | +//! such as _GRUB_ or _Limine_, passed the UEFI memory map as part of the |
| 29 | +//! corresponding boot information to your kernel, or to access runtime services |
| 30 | +//! from your kernel. Hence, when you also use utilize `uefi` also in ELF |
| 31 | +//! binaries and are not limited to EFI images. |
| 32 | +//! |
| 33 | +//! ## Supported Architectures |
| 34 | +//! |
| 35 | +//! `uefi` is compatible with all platforms that both the Rust compiler and |
| 36 | +//! UEFI support, such as `i686`, `x86_64`, and `aarch64`). Please note that we |
| 37 | +//! can't test all possible hardware/firmware/platform combinations in CI. |
| 38 | +//! |
| 39 | +//! # API/User Documentation, Documentation Structure, and other Resources |
| 40 | +//! |
| 41 | +//! In this crate documentation, you find a technical API documentation |
| 42 | +//! including various code examples. |
| 43 | +//! |
| 44 | +//! For a TL;DR quick start with an example on how to create your own EFI |
| 45 | +//! application, please check out [the UEFI application template][template]. The |
| 46 | +//! [Rust UEFI Book] is a more beginner-friendly tutorial with How-Tos, and |
| 47 | +//! overviews of some important UEFI concepts and the abstractions provided by |
| 48 | +//! this library. This |
| 49 | +//! |
| 50 | +//! For more details of UEFI, see the latest [UEFI Specification][spec]. |
| 51 | +//! |
| 52 | +//! # Comparison to other Projects in the Ecosystem |
| 53 | +//! |
| 54 | +//! ## Rust `std` implementation |
| 55 | +//! |
| 56 | +//! There is an ongoing effort for a `std` [implementation of the Rust standard |
| 57 | +//! library](https://doc.rust-lang.org/nightly/rustc/platform-support/unknown-uefi.html), |
| 58 | +//! that is yet far from being mature. As of Mid-2024, we recommend to use our |
| 59 | +//! `uefi` library in a `no_std` binary to create EFI images. |
| 60 | +//! |
| 61 | +//! We will closely monitor the situation and update the documentation |
| 62 | +//! accordingly, once the `std` implementation is more mature. |
15 | 63 | //!
|
16 |
| -//! # Crate organisation |
| 64 | +//! ## `r-efi` |
| 65 | +//! |
| 66 | +//! Raw UEFI bindings without high-level convenience similar to our `uefi-raw` |
| 67 | +//! crate, which is part of this project, but more feature-complete. It |
| 68 | +//! targets a lower-level than our `uefi` crate does. |
| 69 | +//! |
| 70 | +//! # Library structure & Tips |
17 | 71 | //!
|
18 | 72 | //! The top-level module contains some of the most used types and macros,
|
19 | 73 | //! including the [`Handle`] and [`Result`] types, the [`CStr16`] and
|
20 | 74 | //! [`CString16`] types for working with UCS-2 strings, and the [`entry`] and
|
21 | 75 | //! [`guid`] macros.
|
22 | 76 | //!
|
| 77 | +//! ## UEFI Strings |
| 78 | +//! |
| 79 | +//! Rust string literals are UTF-8 encoded and thus, not compatible with most |
| 80 | +//! UEFI interfaces. We provide [`CStr16`] and [`CString16`] for proper working |
| 81 | +//! with UCS-2 strings, including various transformation functions from standard |
| 82 | +//! Rust strings. You can use [`ctr16!`] to create UCS-2 string literals at |
| 83 | +//! compile time. |
| 84 | +//! |
23 | 85 | //! ## Tables
|
24 | 86 | //!
|
25 | 87 | //! The [`SystemTable`] provides access to almost everything in UEFI. It comes
|
|
73 | 135 | //! only unfold their potential when you invoke `uefi::helpers::init` as soon
|
74 | 136 | //! as possible in your application.
|
75 | 137 | //!
|
| 138 | +//! # Discuss and Contribute |
| 139 | +//! |
| 140 | +//! Feel free to file bug reports and questions in our [issue tracker], and [PR |
| 141 | +//! contributions][contributing] are also welcome! |
| 142 | +//! |
| 143 | +//! You can discuss with us in our [Zulip]. |
| 144 | +//! |
| 145 | +//! # MSRV |
| 146 | +//! <!-- Keep in Sync with README! --> |
| 147 | +//! |
| 148 | +//! The minimum supported Rust version is currently 1.70. |
| 149 | +//! Our policy is to support at least the past two stable releases. |
| 150 | +//! |
| 151 | +//! # License |
| 152 | +//! <!-- Keep in Sync with README! --> |
| 153 | +//! |
| 154 | +//! The code in this repository is licensed under the Mozilla Public License 2. |
| 155 | +//! This license allows you to use the crate in proprietary programs, but any |
| 156 | +//! modifications to the files must be open-sourced. |
| 157 | +//! |
| 158 | +//! The full text of the license is available in the [license file][LICENSE]. |
| 159 | +//! |
| 160 | +//! # Trivia and Background |
| 161 | +//! |
| 162 | +//! [UEFI] started as the successor firmware to the BIOS in x86 space and developed |
| 163 | +//! to a universal firmware specification for various platforms, such as ARM. It |
| 164 | +//! provides an early boot environment with a variety of [specified][spec] |
| 165 | +//! ready-to-use "high-level" functionality, such as accessing disks or the network. |
| 166 | +//! EFI images, the files that can be loaded by an UEFI environment, can leverage |
| 167 | +//! these abstractions to extend the functionality in form of additional drivers, |
| 168 | +//! OS-specific bootloaders, or different kind of low-level applications. |
| 169 | +//! |
| 170 | +//! [LICENSE]: https://github.com/rust-osdev/uefi-rs/blob/main/uefi/LICENSE |
76 | 171 | //! [Rust UEFI Book]: https://rust-osdev.github.io/uefi-rs/HEAD/
|
77 | 172 | //! [UEFI]: https://uefi.org/
|
| 173 | +//! [Zulip]: https://rust-osdev.zulipchat.com/ |
78 | 174 | //! [`BootServices`]: table::boot::BootServices
|
79 | 175 | //! [`GlobalAlloc`]: alloc::alloc::GlobalAlloc
|
80 | 176 | //! [`SystemTable`]: table::SystemTable
|
| 177 | +//! [`ctr16!`]: crate::cstr16 |
81 | 178 | //! [`unsafe_protocol`]: proto::unsafe_protocol
|
82 | 179 | //! [contributing]: https://github.com/rust-osdev/uefi-rs/blob/main/CONTRIBUTING.md
|
83 | 180 | //! [issue tracker]: https://github.com/rust-osdev/uefi-rs/issues
|
84 | 181 | //! [spec]: https://uefi.org/specifications
|
| 182 | +//! [template]: https://github.com/rust-osdev/uefi-rs/tree/main/template |
85 | 183 | //! [unstable features]: https://doc.rust-lang.org/unstable-book/
|
86 | 184 |
|
87 | 185 | #![cfg_attr(all(feature = "unstable", feature = "alloc"), feature(allocator_api))]
|
|
0 commit comments