Copy MSRV, License, and Contributing sections to lib.rs and streamline it
with the README equivalents. We should also include these information in
lib.rs, as it is the main entry point into everything relevant about the
library. At least, it should from now on.
The big benefit is that the documentation on `docs.rs` then covers
everything relevant.
The main idea here is to:
- tell that `uefi` is not only for EFI images but also apps that interact with
UEFI functionality, such as parsing a memory map from a pre-defined chunk of
memory.
- streamline the doc (cargo.toml, README, lib.rs)
These sections were mostly duplicated between the top-level readme and the
`uefi` package's readme. In the top-level readme, it had a broken link to the
`BUILDING.md` document which has been deleted.
Since we now have "Documentation" sections in both those readmes, the "Building
UEFI programs" section was mostly redundent, except for the part about MSRV. Add
new MSRV sections, and in the top-level readme just link to the `uefi` package's
readme so that we don't have to update both places when the MSRV changes.
This requires an MSRV bump to 2022-11-22. (The build-std targets were
actually added in 2022-11-10, but there were some bugs in the dist at
that time that cause linker errors on i686.)
The feature lists are covered in the crate docstrings now, and the crate
READMEs link to that source as well. Drop the list here so we don't have
to worry about keeping them in sync.
To prevent confusion, this renames the `alloc` crate feature to
`global_allocator` and the `exts` feature to `alloc` to match the
conventions of the ecosystem.
`cargo xtask run --example <name>` can now be used to run an
example. There are no examples to actually run yet, they will be added
in a later commit.
There's some added complexity here to get commands like `build` and
`clippy` to include the examples, see the long comment on `TargetTypes`
for details.
To make examples run faster, the QEMU runner does not set up the network
stuff (tftp and echo service) when running an example.
Add a `rust-toolchain.toml` file that specifies the channel and
components needed to build uefi-rs. See
https://rust-lang.github.io/rustup/overrides.html#the-toolchain-file for
documentation of the `rust-toolchain.toml` format.
Remove the `--toolchain` option from `xtask`, as using this file is a
simpler alternative. Also remove the instructions for installing the
nightly toolchain from the readme, as `rustup` will do this
automatically now.
The template application has been updated to add a
`rust-toolchain.toml`, and `BUILDING.md` has been updated to mention it
as well.
The `toolchain` action previously used in the CI is unmaintained and
doesn't understand `rust-toolchain.toml` (it does understand the older
`rust-toolchain` file, but that doesn't allow for including required
components). Since the runners come with rustup already installed, we
don't actually need a complex action here anyway, so just remove those
sections entirely. A few jobs need extra components installed, do that
with `rustup component add`.
Note that this change will also cause `xtask` itself to be built with
nightly. That should generally be fine, we only had it using stable
because of https://github.com/rust-osdev/uefi-rs/issues/397, and in the
future we can easily temporarily pin to a non-current nightly if a bug
occurs with an `xtask` dependency again.
Fixes https://github.com/rust-osdev/uefi-rs/issues/498
This corresponds to the `i686-unknown-uefi` rust triple. The test runner
seems to work fine without any changes, so remove the note in the readme
saying the crate has only been tested on 64-bit.
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.
build.py isn't really specific to uefi-test-runner; it has commands for
generating docs, running clippy, and running tests. Move it to the root
of the repo to reflect its broader role.
Updated various docs that reference build.py.
Rust now supports uefi as a build target: https://github.com/rust-lang/rust/pull/56769
This change mainly eliminates references to the custom JSON target
file. It also requires that the entry point's name be changed to
`efi_main`.
Note that the "C" abi is now correct for EFI applications, but will
still be incorrect when uefi-rs is brought in as an external dependancy
for a different target. This means the entry point should always be
`extern "C"` while the table of function pointers should be `extern
"win64"`.
Nicholas Bishop