Apparently, still a lot of people are using uefi-services, probably mostly due to
auto-upgrades. This seems to cause upgrades when people keep upgrading `uefi`
while still using an outdated version of `uefi-services`.
This update will cause everyone using auto-updates to either rethink to pin
their crate versions or to finally migrate.
Mark a few new functions `const` to satisfy clippy lints.
Also drop the "Keep in Sync with README!" comment for the MSRV doc; it's not in
the readme anymore.
The code for trying to find where the OS has installed OVMF files has been
removed. You can still pass your own OVMF files in via command-line or env vars,
but by default the code will download prebuilt OVMF files from
https://github.com/rust-osdev/ovmf-prebuilt.
Add a `docsrs` config in the `docs.rs` metadata in Cargo.toml. This will
set `--cfg docsrs` when building on docs.rs. Enable the `doc_auto_cfg`
feature when the `docsrs` config is enabled. This feature is currently
unstable, but docs.rs uses a nightly compiler so this works fine.
The effect of this is that docs.rs will show a badge for items that are
only available if some feature is enabled. For example,
`BootServices::find_handles` will have a badge saying "Available on
crate feature exts only."
To view this locally, run this:
```
RUSTDOCFLAGS="--cfg=docsrs" cargo +nightly doc --all-features --open
```
This change has only been applied to the `uefi` package, since the
`uefi-macros` package does not have any features and the `uefi-services`
package's features don't control the visiblity of any public items.
https://github.com/rust-osdev/uefi-rs/issues/486
Allow older versions of some dependencies to be used if that's all
that's available. This change will have no effect for typical builds
with Cargo, as Cargo will just pick the latest version and download
it. But in more restrictive/sandboxed build environments where the
latest versions of packages might not be available, it's helpful to
allow a wider range of versions.
Only non-dev dependencies have been changed, and only in the three
published packages.
Tested locally by temporarily prefixing these depdency versions with `=`
to force Cargo to use exactly that version, and verifying that
build/test/run commands still worked.
This is a rewrite of the Python build.py code in Rust. See
https://github.com/matklad/cargo-xtask for details of the xtask
pattern. Essentially it's a pattern for extending cargo with
project-specific commands. Using Rust gives all the usual benefits of
checking stuff at compile time, thorough error handling, ease of
testing, etc. It is more verbose though, so the LOC goes up a bit.
* Removed `build-std` settings from `.cargo/config` because we want to
run `xtask` with the default compiler config. The various `cargo
xtask` commands handle adding the build-std args where needed. This
has the side effect of obsoleting the
`uefi-macros/tests/cargo_wrapper` hack.
* The build subcommand now builds the whole workspace (except for xtask,
since that implicitly has already been built). So no separate CI step
to test that the `tmplate` package builds is needed.
* Dropped the `--verbose` option, just always print the commands being
run since it's helpful info.
* Looked like there was some vestigial timeout code for the VM test but
no timeout was set that I could see; added a timeout to the github
workflow yaml instead.
Add `use core::arch::asm` in a couple places, and add a temporary
override of the qemu-exit dep to point at a branch with the asm fix.
Partially fixes https://github.com/rust-osdev/uefi-rs/issues/329 (but
keep it open until qemu-exit can be switched back to a normal release.)
This adds a new crate under `template/` that contains a very minimal UEFI
application. The instructions in `BUILDING.md` have been updated to reference
the template instead of using inline code snippets.
I think this makes it a bit easier to get started with a new app -- you can
just copy the whole directory and make a couple changes in `Cargo.toml` to get
started. `uefi-test-runner` is similar, but has a lot more stuff in it so it's
harder to see exactly what is needed. Moving the code out of markdown also
makes it easier to test in github actions to ensure the code stays valid.
