Skip to content

uefi: add boot::[un_]install_multiple_protocol_interface() #1856

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Draft
phip1611 wants to merge 4 commits into
base: main
Choose a base branch
from
Draft

uefi: add boot::[un_]install_multiple_protocol_interface() #1856

phip1611 wants to merge 4 commits into from
+387 −21

Conversation

@phip1611
Copy link
Member

@phip1611 phip1611 commented Jan 1, 2026

This ultimately adds and tests boot::install_multiple_protocol_interface() and boot::uninstall_multiple_protocol_interface() (see #302). Further, it streamlines multiple things and adds pre-requisites:

  • We were inconsistent in our API: sometimes we consume <P: ProtocolPointer + ?Sized> and sometimes proto: &Guid
    • Inconsistency is always bad
    • The generic-based approach is not usable if the GUID is only available at runtime
  • Therefore, I refactored multiple functions to use the generic-based API for consistency and added _by_guid counterparts
  • These ultimatively also enabled me to implement install_multiple_protocol_interface()

Checklist

  • Sensible git history (for example, squash "typo" or "fix" commits). See the Rewriting History guide for help.
  • Update the changelog (if necessary)

@phip1611 phip1611 mentioned this pull request Jan 1, 2026
Open
@phip1611 phip1611 self-assigned this Jan 1, 2026
@phip1611 phip1611 force-pushed the install-protocol-interface branch 3 times, most recently from 74dd331 to e34f624 Compare January 1, 2026 22:29
@phip1611
uefi: protocols: cleanup test_protocol[_by_guid]()
15b2c29 
The majority of our protocol-related public functions use a generic
approach with `<P: ProtocolPointer + ?Sized>`. Unfortunately:

- we are inconsistent with that
- this hinders some use-cases where the GUID is only known at
  runtime

Therefore, this is the first commit of a series of commits that
improves the situation by providing base functions that use the
generic-based API and `by_guid` counterparts for more runtime-
flexibility.
@phip1611
uefi: protocols: cleanup register_protocol_notify[_by_guid]()
8daafb1
@phip1611
uefi: protocols: cleanup [re_,un_]install_protocol_interface()
0a8f6c6
@phip1611
uefi: add boot::[un_]install_multiple_protocol_interface()
8820a0e 
Having these functions is very helpful if one installs multiple protocol
interfaces in a driver at once. The caveat is unfortunately that Rust
handling of varargs isn't very convenient. I also didn't come up with
a working + nice way using normal macros to workaround.

Instead, I looked into the implementation in edk2 [0]. The logic is
fairly simple and can be emulated on a higher-level by us.

[0] https://github.com/tianocore/edk2/blob/66346d5edeac2a00d3cf2f2f3b5f66d423c07b3e/MdeModulePkg/Core/Dxe/Hand/Handle.c#L630
@phip1611 phip1611 force-pushed the install-protocol-interface branch from e34f624 to 8820a0e Compare January 2, 2026 12:44
@phip1611 phip1611 mentioned this pull request Jan 5, 2026
Open
2 tasks
@nicholasbishop
Copy link
Member

nicholasbishop commented Jan 20, 2026

A design question: is it worth having the non-GUID versions of these functions? As you note, "the generic-based approach is not usable if the GUID is only available at runtime". Any existing use of a generic function can be trivially rewritten to use the GUID version by calling SomeProtocol::GUID. By having two versions of the function, we make the user think about which one to pick, even though they are functionally identical. I think the main reason to have a generic function would be performance, but installing/uninstalling/testing protocols is unlikely to be done in a hot loop.

I agree the inconsistency with having some functions take a GUID and others a generic arg is ugly though. Perhaps we could come up with a migration plan to get rid of the generic versions entirely?

@phip1611
Copy link
Member Author

phip1611 commented Jan 25, 2026 •
edited
Loading

A design question: is it worth having the non-GUID versions of these functions? As you note, "t

I agree the inconsistency with having some functions take a GUID and others a generic arg is ugly though. Perhaps we could come up with a migration plan to get rid of the generic versions entirely?

Yes, 100%. I agree. I'll create a ticket: #1878

@phip1611 phip1611 marked this pull request as draft January 25, 2026 11:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@nicholasbishop nicholasbishop Awaiting requested review from nicholasbishop

Assignees

@phip1611 phip1611

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@phip1611 @nicholasbishop