Skip to content

v15.1.0

Choose a tag to compare

View all tags
@github-actions github-actions released this 14 May 20:44
· 985 commits to refs/heads/main since this release
v15.1.0
05bc41c

What's Changed

  • Prevent panic when debug printing BS and RT services before init @makubacki (#417)
    Change Details
      ## Description

    Currently, the debug implementation attempts to print everything which then causes a panic if the service table is not initialized yet.

    This is especially an issue when dumping other structures with debug prints that may contain uninitialized services tables.

    Minor miscellaneous cleanup in surrounding code is included.

    • Impacts functionality?
    • Impacts security?
    • Breaking change?
    • Includes tests?
    • Includes documentation?

    How This Was Tested

    • Dump uninitialized structures during QEMU boot
    • Unit tests

    Integration Instructions

    • N/A

  • [REBASE \& FF] Implement Memory Manager Service for DXE Core @cfernald (#330)
    Change Details
      ## Description

    Implements the MemoryManager API for the core and publishes as a Service. This introduces an empty static structure that is intended both for internal used through references to the CoreMemoryManager as well as externall through dependency injection for Service<dyn MemoryManager>.

    This initial change is just to introduce the service and does not yet attempt to consume internally or cleanup existing API use cases. These will come in a later PR.

    • Impacts functionality?
    • Impacts security?
    • Breaking change?
    • Includes tests?
    • Includes documentation?

    How This Was Tested

    • Tested on Q35 with included integrations tests.
    • All existing tests pass

    Integration Instructions

    N/A



  • .github: Re-enable cargo release dry-run @Javagedes (#403)
    Change Details
      ## Description
    • Impacts functionality?
    • Impacts security?
    • Breaking change?
    • Includes tests?
    • Includes documentation?

    How This Was Tested

    N/A

    Integration Instructions

    N/A



🚀 Features & ✨ Enhancements

  • [REBASE\&FF] Support Services as static references @Javagedes (#411)
    Change Details
      ## Description

    Updates the IntoService derive macro to additionally implement IntoService for a static reference of a struct, not just a concrete instance. This is to support scenarios where a developer must maintain their own static instance of the concrete type but want to be able to register that concrete instance as a service.

    This scenario specifically came up when implementing a service that is also the backing functionality for an EDKII protocol where the protocol did not take a pointer to self as it's first parameter.

    • Impacts functionality?
    • Impacts security?
    • Breaking change?
    • Includes tests?
    • Includes documentation?

    How This Was Tested

    Unit Tests

    Integration Instructions

    Users may now register static references as services as seen below:

    static MY_STRUCT: MyStruct = MY_STRUCT::new(50);

fn entry_point(mut commands: Commands) -> Result<()> {
    commands.add_service(&MY_STRUCT);
}
      </blockquote>
  <hr>
</details>

📖 Documentation Updates

  • Switch to a public registry (`patina-fw`) [Rebase \& FF] @makubacki (#409)
    Change Details
      ## Description

    Closes #398

    Switch to a public registry (patina-fw)

    Moves to a temporary Azure Artifacts feed that serves as the Patina crate registry until the project's crates are published to crates.io.

    Connect to the crate in a .cargo/config.toml with:

    [registries]
temporary = { index = "sparse+https://pkgs.dev.azure.com/patina-fw/crates/_packaging/temporary/Cargo/index/" }

    Feed URL:

    https://dev.azure.com/patina-fw/crates/_artifacts/feed/temporary

    Additional Setup Instructions:

    https://dev.azure.com/patina-fw/crates/_artifacts/feed/temporary/connect

    Special Note

    To clarify terminology the following are involved in the public feed:

    • Organization: patina-fw
    • Project: crates
    • Feed: temporary

    Originally, I tried making "crates.io" an upstream of the temporary feed so we could use a single feed for our published crates while also caching upstream crates using contributor permission in CI and for local users.

    This would only work if the crates repository was set to enterprise access level, not public. In that case, the feed is also not public, which defeats the purpose of this change. A 401 occurs when the feed attempts to pull in the crate version from crates.io. This happens whether using a PAT (with proper permissions) or MSAL with msrustup as an authenticator. By simply making the project, enterprise both approaches begin working with the exact same token.

    Therefore, the PR has been updated to pull all crates on crates.io from crates.io and only allow publishing to the patina-fw feed and also set up all crates published to that feed to be fetched from there.

    Special Note 2

    cargo release does not seem to honor the registry setting for each dependency in the workspace Cargo.toml file. It was working previously based on the complete replacement of crates-io with:

    [source.crates-io]
replace-with = "UefiRust"

    Due to Special Note above, that's not possible with this registry as we can only use it for crates not being pulled from crates.io upstream.

    After trying several approaches, the one that seems to work and is the least hacky is to patch each crate that would go to the crates-io registry to the local crate with:

    [patch.crates-io]
dxe_core = { path = "core/dxe_core" }

    Therefore, an update has been made to do that for every crate published in this repo.

    An outstanding issue is that the mtrr and paging crates are not local to this repo but also not on crates.io. Therefore, this does not directly apply to those crates.

    There are at least three ways to solve that:

    1. Make the mtrr and paging crates public and publish their crates to crates.io
    2. Move the mtrr and paging crates to the patina repo so they become "local paths"
    3. Patch the mtrr and paging crates as git dependencies to their current ODP repo locations
    4. Patch the mtrr and paging crates back to the patina-fw registry.

    • (1) is ideal and simplest if we're ready to publish those crates

      • Note: paging is already taken on crates.io, so it will need to be renamed, which is inevitable anyway.

    • (2) is less ideal since it defeats the separation of these crates into their own repos and the separation, we wanted for those crates from the rest of the Patina code.

    • (3) is even less ideal because:

      • Private ODP GitHub repos (which these are) would still need to be authenticated in CI which is another layer of complexity to add.

      • The publish step will be referencing the main branches of those repos which is different from the other cargo commands operating on the workspace dependencies

      • Because other cargo commands are using the "real" mtrr and paging crates, this warning will appear with the patches present when running commands like `cargo update:

        Updating `patina-fw` index
warning: Patch `mtrr v0.1.1 ([https://github.com/OpenDevicePartnership/mtrr.git?branch=main#ab5369bc)`](https://github.com/OpenDevicePartnership/mtrr.git?branch=main#ab5369bc)%60 was not used in the crate graph.
Perhaps you misspelled the source URL being patched.
Possible URLs for `[patch.<URL>]`:
    patina-fw
warning: Patch `paging v4.0.2 ([https://github.com/OpenDevicePartnership/paging.git?branch=main#218277d8)`](https://github.com/OpenDevicePartnership/paging.git?branch=main#218277d8)%60) was not used in the crate graph.      
Perhaps you misspelled the source URL being patched.
Possible URLs for `[patch.<URL>]`:
    patina-fw

    • (4) was chosen to solve this problem immediately with work on (1) in progress as a long-term solution.

    • Impacts functionality?
    • Impacts security?
    • Breaking change?
    • Includes tests?
    • Includes documentation?

    How This Was Tested

    • cargo update locally
    • cargo build in CI
    • cargo release (dry run) locally and in CI

    Integration Instructions

    • The crate will now be published to a public ADO registry. Connect to it as follows:
    [registries]
temporary = { index = "sparse+https://pkgs.dev.azure.com/patina-fw/artifacts/_packaging/temporary/Cargo/index/" }

      </blockquote>
  <hr>
</details>
  • Update Patina repo documentation (first pass for mono repo) @makubacki (#404)
    Change Details
      ## Description

    Updates references to old repos and processes to those now used in the Patina "mono repo". Future updates will come to add more details (as opposed to patching old details and references) about working in the Patina repository and to reflect upcoming changes that will involve renaming crates.

    • Impacts functionality?
    • Impacts security?
    • Breaking change?
    • Includes tests?
    • Includes documentation?

    How This Was Tested

    • CI

    Integration Instructions

    • N/A

Full Changelog: v15.0.0...v15.1.0

Contributors

cfernald, makubacki, and Javagedes
Assets 2
Loading