-
-
Notifications
You must be signed in to change notification settings - Fork 177
Implement base for PCI Root bridge io protocols #1724
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
base: main
Are you sure you want to change the base?
Conversation
|
||
impl Drop for PciMappedRegion<'_, '_> { | ||
fn drop(&mut self) { | ||
let status = unsafe { (self.proto.unmap)(self.proto, self.key) }; |
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.
Would it make sense to add a fn unmap(self) -> Result
method, so that callers can choose to handle errors from unmapping? The Drop
trait doesn't really allow that. I think the drop implementation should probably not panic on errors, and that we should remove the unreachable
; UEFI implementations sometimes return additional errors beyond what the spec includes.
Ditto for the PciPage
implementation.
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.
True, I initially put unreachable macro there to indicate that "errors that may happen according to spec are all handled and no other error can occur"
But yeah second thought we can never be sure
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.
Tho, what else should it do when an error occurs? Should I make it undroppable(assuming it's possible) so that users must use functions like unmap?
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.
There's no way to make something undroppable in Rust, unfortunately. There are two options:
- A 'drop bomb', i.e. panic unconditionally in
drop
ifunmap
wasn't called. The documentation should strongly remind the user thatunmap
must be called. - Handle errors in drop by ignoring them (or log them and otherwise ignore). The documentation can encourage users to call
unmap
for better error handling, but it's not required. This is whatFile
does, for example; it suggests callingsync_all
beforedrop
if you want to handle errors.
In cases where errors are unlikely (which I think is the case here), I prefer the 2nd option; log errors in drop
but otherwise ignore them.
Well test fails on windows because it can't use new pci memory device |
Might need to just skip this test on Windows. Take a look at https://github.com/rust-osdev/uefi-rs/blob/main/xtask/src/main.rs#L149 for examples of how we control test features. |
This is continuation of #1705
As requested by @phil-opp I decided to split the pr into multiple.
This one only contains base for the upcoming other PRs.
Specifically, it contains wrapper for pages allocated and regions mapped by the protocol.
and it adds new pci device with big memory for testing memory protocols later.
Since no protocol is submitted yet users wont be able to use this for now.
Checklist