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
Clarify error codes #51
Conversation
It mentions the firmware extensions of #43, which isn't merged yet, but seems to have reached consensus. |
#43 has been merged. See also parallel discussion regarding the OpenSBI handling of error codes: |
Every function defined in the specification has a set of error codes associated | ||
with a case in which they are returned. In the even of such a case, that error | ||
code must be returned. No other error code must be returned. |
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.
Perhaps a slight tweak to the wording? Maybe something like:
Every function defined in the specification has a set of error codes along with the associated cases in which they are returned. Only in those cases may the indicated error code be returned. Any other error codes must never be returned.
Do you agree with latest comment on that thread ? |
If you are talking about the proposal to allow any function to return SBI_ERR_FAILED for any unlisted reason, then no I don't agree. I generally think about errors in terms of how the caller is meant to respond to them, and the generic catch all leaves too many questions:
If there is going to be a catch all error codes, I'd rather they be a deliberate choice on a per-function basis, and ideally include a 1-2 sentence hint of what sort of conditions might causes them. It also means that individual extensions can chose to require infallible functions, as the base functionality extension does now: "All functions in the base must be supported by all SBI implementations, so there are no error returns defined." |
@fintelia : Is it okay if we continue the discussion in the mailing list ? I am afraid that some context may be lost between the github issue & mailing list discussion ? I will wait for your confirmation to continue the discussion in the right forum. |
I agree we should consolidate this discussion. I'd say that the RISC-V Platform Spec is probably the right list for this, though I think the last thread was actually on the OpenSBI list (with a handful of people CC'd, including myself) |
Closing this PR as the detailed discussion happened in the mailing list and appropriate patches have been merged to OpenSBI. |
See discussion on the mailing list: https://lists.riscv.org/g/tech-unixplatformspec/topic/74267659