-
Notifications
You must be signed in to change notification settings - Fork 162
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.
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
Implement additional BootServices
functions
#550
Implement additional BootServices
functions
#550
Conversation
Hi @timrobertsdev, the markup regarding the checkboxes is intended to be used like this:
as this way, checkboxes will be rendered properly, as here
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. What do @GabrielMajeri and @nicholasbishop think?
The code looks very good, just waiting for some tests to be added and it's good to go. |
@phip1611 Thanks for the heads up, I wasn't aware of the markup formatting. Tests are in now. Some changes to |
Please rebase on latest |
I thought that what I just did would rebase onto main and then put my commits over it but I guess I didn't do that quite right. @nicholasbishop would you be able to help out my failing git-fu? |
I think maybe you rebased but your
Or, equivalently but without updating the local
|
That was it, I had sync'd my fork in github but forgot to actually update my local Edit: About to do it again because I didn't notice the last merge to |
- Implement `BootServices::install_protocol_interface` - Implement `BootServices::uninstall_protocol_interface` - Implement `BootServices::reinstall_protocol_interface` - Implement `BootServices::register_protocol_notify` - Add `SearchType::ByRegisterNotify` variant. - Add `SearchType::from_search_key` - Add `SearchKey` type that abstracts over an opaque pointer given by `BootServices::register_protocol_notify`.
@@ -1,6 +1,7 @@ | |||
#![no_std] | |||
#![no_main] | |||
#![feature(abi_efiapi)] | |||
#![feature(negative_impls)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't see why this is required. Can you please give some details?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, rustc
said it was required when I was implementing my dummy protocol with #[derive(Protocol]
.
Specifically in uefi-test-runner/src/boot/misc.rs
:
/// Dummy protocol for tests
#[unsafe_guid("1a972918-3f69-4b5d-8cb4-cece2309c7f5")]
#[derive(Protocol)]
struct TestProtocol {}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, thanks for the pointer. What does @nicholasbishop say? Is this fine?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is fine, just a consequence of the way we implement protocols.
(There's a little bit of commentary on negative_impl
in #452; it might be something we want to drop in the future. But for this PR it's fine.)
@@ -112,7 +112,7 @@ fn test_install_protocol_interface(bt: &BootServices) { | |||
.expect("Failed to install protocol interface") | |||
}; | |||
|
|||
let exists = bt | |||
let _ = bt |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: These changes could be squashed with the commit(s) where the changes were introduced.
However, this is not a hard requirement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to learn git a bit better anyway, so I'll see what I can do about cleaning up the history a bit today.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Moving things between existing git commits is kinda hard without experience. In the last months, I've spent some time on improving my skills. The following workflow worked for me. Maybe it helps you as well, hopefully:
git rebase --interactive HEAD~4
(for four commits)- in the editor, mark all commits you want to change with
e
/edit
- run
cargo fmt
&&cargo clippy
plusgit add
all changes - run
git rebase --continue
- While commits are left, goto 3.
Ideally, git should discard the "code style only commit" if you can pull these changes into earlier commits this way. Let me know what worked for you! :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That actually was a really easy way to understand how to split commits apart, thanks! I had no idea that git would detect and let you remove empty commits.
Thanks for the contribution. I'd wait with the merge until @nicholasbishop addressed the comment above. |
Adjust changelog Rename `SearchKey` to `ProtocolSearchKey` and move to `boot.rs`. Fixup doclinks. Adjust signatures of the `[re/un]install_protocol_interface` functions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm, thanks :)
This PR implements basic protocol handler services such as
(re/un)install_protocol_services
and allows a user to be notified when a protocol is installed through the implementation ofregister_protocol_notify
. To support the implementation ofregister_protocol_notify
, a variant was added toSearchType
and any functions using it updated. A new typeSearchKey
was added to abstract over the void pointer given byregister_protocol_notify
.There was one
enum
added to supportinstall_protocol_services
that currently has only one variant, 'InterfaceType'. I have chosen to make thisenum
public to be forwards-compatible, but in the implementation ofinstall_protocol_services
I don't include aninterface_type
parameter yet asInterfaceType
and simply pass the only variant. I'm not quite sure if this "middle of the road" solution is ideal and am looking for feedback.Tests will be coming soon.
Checklist