uefi std: add example and add book chapter #1331
Conversation
phip1611
force-pushed
the
uefi-std
branch
3 times, most recently
from
87cd184 to
722eeeb
Compare
book/src/tutorial/rust-std.md
Outdated
| In the `uefi` crate, we provide tooling to create a `no_std` + `no_main` | ||
| binary, i.e., an UEFI image, in a convenient way. However, there is also the | ||
| option to create a "standard" binary with Rust. The result is the same, but the | ||
| build process and the overall programming is much more similar to regular |
There was a problem hiding this comment.
nit: the build process is the same either way right? cargo build --target <uefi-target>
book/src/tutorial/rust-std.md
Outdated
| instead. Just as you would to in the typical Linux application, for example. | ||
|
|
||
| The `uefi` crate is suited to extend the functionality of these "standard | ||
| binaries". |
There was a problem hiding this comment.
The three sections above are essentially all "what is uefi + std" -- I think it would be clearer to shorten down to a quick explanation that there is ongoing work to add more support for std to the UEFI targets in rust with link(s) to where more info can be found, then show the example.
There was a problem hiding this comment.
Yeah, I also wasn't that happy with them. Do you like the new version better?
book/src/tutorial/rust-std.md
Outdated
| implementation is not feature-complete and work in progress | ||
| (Mid-2024, Rust stable 1.80), and will also be it in the coming months and | ||
| probably years. Over time, you will need less and less specific features of | ||
| `uefi` and can utilize standard and well-known OS-independent APIs in `std` |
There was a problem hiding this comment.
I think we should avoid making claims about it being recommended or not -- we can stick to just the facts and note that uefi+std is still in progress and gated by an unstable flag.
There was a problem hiding this comment.
I hope the new phrasing is better?
book/src/how_to/rust-std.md
Outdated
| binary, i.e., an UEFI image, in a convenient way by providing a `#[entry]` | ||
| macro for the crate's main function. However, after ongoing efforts in upstream | ||
| Rust, there is also the option to create a "standard" binary for UEFI. The | ||
| result is the same, but the build process and the overall programming experience |
There was a problem hiding this comment.
result -> the compiled result
book/src/how_to/rust-std.md
Outdated
|
|
||
| ## About | ||
|
|
||
| In the `uefi` crate, we provide tooling to create a `no_std` + `no_main` |
There was a problem hiding this comment.
I'm still not 100% satisfied with the phrasing of this paragraph. Any idea?
There was a problem hiding this comment.
One thing that would help I think is to drop the "standard binary" terminology; stick to no_std and the std crate.
Here's my attempt:
Programs created with the uefi crate are typically created with no_std and no_main. A no_std crate can use the core and alloc parts of Rust's standard library, but not std. A no_main executable does not use the standard main entry point, and must define its own entry point; uefi provides the entry macro for this purpose.
Rust has added partial support for building UEFI executables without no_std and no_main. Some functionality requires a nightly toolchain, and some parts of std are gated by the unstable uefi_std feature. Follow the tracking issue for details.
This is a prerequisite for the next step.
|
Ready for review. What do you think? Is this a better version? |
Split-out of #1292. This adds an example for a Rust standard binary for UEFI that utilizes
uefion top of that. It also adds a chapter to the book.Checklist