Create a skeleton UEFI app #2605
Conversation
andrisaar
force-pushed
the
uefi
branch
2 times, most recently
from
b69dcb9 to
baf8fe1
Compare
andrisaar
changed the title
| use uefi::{prelude::*, table::runtime::ResetType, ResultExt}; | ||
|
|
||
| #[entry] | ||
| fn _start(_handle: Handle, mut system_table: SystemTable<Boot>) -> Status { |
There was a problem hiding this comment.
Does this need to be named _start or is it just a convention? Either way, could you link to some reference material?
There was a problem hiding this comment.
Just a convention. I've added some comments.
There was a problem hiding this comment.
Great, thanks! This stuff is pretty new for everyone, including people familiar with "vanilla" Rust, so expect to have to over communicate / document things :)
| main(_handle, &mut system_table) | ||
| }; | ||
|
|
||
| system_table |
There was a problem hiding this comment.
Could you add some comment here to explain what's happening (and why)?
| #![feature(abi_efiapi)] | ||
| #![feature(custom_test_frameworks)] | ||
| #![test_runner(crate::test_runner)] | ||
| #![reexport_test_harness_main = "test_main"] |
There was a problem hiding this comment.
Where does the test_main string come from? Is it important that it stays like that, or can it be changed? Please add some details
There was a problem hiding this comment.
I assume it can be changed; I've added a link to the blog post this code draws upon heavily for the testing infrastructure.
experimental/uefi/src/main.rs
Outdated
|
|
||
| let status = writeln!(system_table.stdout(), "Hello World!"); | ||
|
|
||
| match status { |
There was a problem hiding this comment.
Can this be expressed more "functionally"? e.g. status.map(|_| SUCCESS).or(DEVICE_ERROR) or something like that
There was a problem hiding this comment.
I could do status.map_or_else(|_| DEVICE_ERROR, |_| SUCCESS) but quite frankly I think that's more opaque and hard to read than that simple match.
Ideally you'd have something like Status::from(status), but it doesn't look that trait is implemented by default. The opposite (turning a Status into a Result) works, though.
There was a problem hiding this comment.
I agree, map_or_else is quite unreadable unless you know exactly which way around the args are.
I think the version of what I suggested that actually works would be status.map(|_| SUCCESS).unwrap_or(ERROR) (which I personally think reads like idiomatic Rust).
There was a problem hiding this comment.
Yeah, that's much better. Done.
| #[entry] | ||
| fn _start(_handle: Handle, mut system_table: SystemTable<Boot>) -> Status { |
There was a problem hiding this comment.
I imagine some of this will end up being part of some generic harness library, while some other parts will be Oak-specific. Not in this PR, but it may be worth start thinking about that split going forward.
| use uefi::{prelude::*, table::runtime::ResetType, ResultExt}; | ||
|
|
||
| #[entry] | ||
| fn _start(_handle: Handle, mut system_table: SystemTable<Boot>) -> Status { |
There was a problem hiding this comment.
Great, thanks! This stuff is pretty new for everyone, including people familiar with "vanilla" Rust, so expect to have to over communicate / document things :)
|
Reproducibility Index: Reproducibility Index diff: |
|
nice, was interesting read :) |
This adds a skeleton UEFI "hello world" The whole goal is to have something that we can start integrating into our build/CI systems.
Case in point, for now
experimental/uefineeds to be excluded in the rootCargo.tomlbecause commands that execute from the root directory (egcargo udeps) fail. This is because Cargo will only read the.cargo/config.tomlfile from the current durectory, but right now the only way to set all of it up properly is to use a.cargo/config.tomlunderexperimental/uefias we need some experimental features. This means that if you run, say,cargo docfromexperimental/uefiit will succeed, but running it from the root directory will fail.There is hope that the
per-package-targetCargo feature will (eventually) help us, but we'll need to wait for rust-lang/cargo#9451 (or something equivalent) to be submitted before we can start using it.