Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

JohnAZoidberg
Copy link
Contributor

@JohnAZoidberg
Copy link
Contributor Author

It mentions the firmware extensions of #43, which isn't merged yet, but seems to have reached consensus.

@JohnAZoidberg
Copy link
Contributor Author

#43 has been merged.

See also parallel discussion regarding the OpenSBI handling of error codes:
http://lists.infradead.org/pipermail/opensbi/2020-May/002185.html

Comment on lines +69 to +71
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.
Copy link
Contributor

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.

@atishp04
Copy link
Collaborator

Do you agree with latest comment on that thread ?

@fintelia
Copy link
Contributor

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:

  • Is the failure permanent, or should the OS retry?
  • Are other functions/extensions also impacted?
  • What actions can the OS take to fix things, or is the only option to record an error and shut down?
  • Why would errors like this happen?

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."

@atishp04
Copy link
Collaborator

@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.

@fintelia
Copy link
Contributor

fintelia commented May 30, 2020

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)

@atishp04
Copy link
Collaborator

Closing this PR as the detailed discussion happened in the mailing list and appropriate patches have been merged to OpenSBI.

@atishp04 atishp04 closed this Oct 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants