-
-
Notifications
You must be signed in to change notification settings - Fork 172
Handle UEFI warnings more cleanly #60
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
Conversation
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 are some things which could be debated but I can't see a more ergonomic solution for now.
The whole design of UEFI's "extensible" warning / error codes pretty much breaks the point of listing the possible error values in the first place 😞 I don't think there's any other way of making error handling convenient and safe in this case.
The latest commit is an experiment towards improving the ergonomics of the |
Alright, the version with the ResultExt extension trait starts to feel like something I could get behind. Feel like taking a second look? |
UEFI has warnings, which represent non-fatal errors. Currently, we treat them as fatal errors, which is somewhat pessimistic. This PR explores a different strategy which allows the user to do various things with warnings including pattern-matching them, logging them silently, or handling them as errors.
Some errors which were previously discarded, such as
EFI_TIMEOUT
in serial communication, are now reported as warnings.Fixes #52.