|
Schaefer, Daniel Helmut (DualStudy) <daniel.schaefer@...>
Hi all,
The SBI spec defines a standard set of error codes, which SBI functions can
return in case of failure (or success). Each function defined in the SBI spec
also defines which error codes it returns in which cases.
My question is:
Can an SBI implementation deviate from these error codes or do the SBI ecalls
have to return the standardized error codes, no more, no less?
If they can, in which way? Do they have to implement the standard error codes
for the listed cases but can return additional error codes for other
non-specified cases?
I'm talking only about the standardized functions. Functions in the vendor
extension and proposed firmware extension could of course do whatever they
want.
Btw. I think we should mention in the riscv-sbi-doc repo, that this ML is the place to discuss SBI.
(It is, right?)
- Daniel
|
|
|
Jonathan Behrens <behrensj@...>
I'd argue that standard functions should only be allowed to return the error codes specifically listed in their descriptions (or SBI_ERR_INVALID_PARAM for invalid hart masks). It makes it way easier for users of the API if they can know in advance what errors could be returned. This is the way I interpreted the current spec, though clarification might be worthwhile.
Jonathan
Hi all,
The SBI spec defines a standard set of error codes, which SBI functions can
return in case of failure (or success). Each function defined in the SBI spec
also defines which error codes it returns in which cases.
My question is:
Can an SBI implementation deviate from these error codes or do the SBI ecalls
have to return the standardized error codes, no more, no less?
If they can, in which way? Do they have to implement the standard error codes
for the listed cases but can return additional error codes for other
non-specified cases?
I'm talking only about the standardized functions. Functions in the vendor
extension and proposed firmware extension could of course do whatever they
want.
Btw. I think we should mention in the riscv-sbi-doc repo, that this ML is the place to discuss SBI.
(It is, right?)
- Daniel
|
|
|
Schaefer, Daniel Helmut (DualStudy) <daniel.schaefer@...>
On 5/17/20 5:20 PM, Jonathan Behrens wrote: I'd argue that standard functions should only be allowed to return the error codes specifically listed in their descriptions (or SBI_ERR_INVALID_PARAM for invalid hart masks). It makes it way easier for users of the API if they can know in advance what errors could be returned. This is the way I interpreted the current spec, though clarification might be worthwhile.
Jonathan
On Sun, May 17, 2020 at 7:36 AM Schaefer, Daniel Helmut (DualStudy) wrote:
Hi all,
The SBI spec defines a standard set of error codes, which SBI
functions can
return in case of failure (or success). Each function defined in the
SBI spec
also defines which error codes it returns in which cases.
My question is:
Can an SBI implementation deviate from these error codes or do the
SBI ecalls
have to return the standardized error codes, no more, no less?
If they can, in which way? Do they have to implement the standard
error codes
for the listed cases but can return additional error codes for other
non-specified cases?
I'm talking only about the standardized functions. Functions in the
vendor
extension and proposed firmware extension could of course do
whatever they
want.
Btw. I think we should mention in the riscv-sbi-doc repo, that this
ML is the place to discuss SBI.
(It is, right?)
- Daniel Yes, my thinking, too. I created a PR with my proposed additions to the spec: https://github.com/riscv/riscv-sbi-doc/pull/51Inline here also: 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. Cases unaccounted for by the specification should use `SBI_ERR_FAILED` and be added in the next version of the SBI specification. Custom SBI calls defined in a vendor or firmware extension can return custom error codes, however it is recommended that they use the standard error codes when appropriate. - Daniel
|
|
|
Jonathan Behrens <behrensj@...>
Is it really necessary to include "Cases unaccounted for by the specification should use `SBI_ERR_FAILED` and be added in the next version of the SBI specification." ? This empowers an implementation to return ERR_FAILED whenever it doesn't feel like executing a function. In the extreme case, you could have an empty implementation that declared "function unimplemented" to be a case that is unaccounted for by the spec, and just returned failure for literally every call. It also isn't clear to me how a supervisor is meant to respond to getting one of these errors. Should it retry until it gets success? Issue a kernel panic? Something else?
Jonathan
On 5/17/20 5:20 PM, Jonathan Behrens wrote:
> I'd argue that standard functions should only be allowed to return the
> error codes specifically listed in their descriptions (or
> SBI_ERR_INVALID_PARAM for invalid hart masks). It makes it way easier
> for users of the API if they can know in advance what errors could be
> returned. This is the way I interpreted the current spec, though
> clarification might be worthwhile.
>
> Jonathan
>
> On Sun, May 17, 2020 at 7:36 AM Schaefer, Daniel Helmut (DualStudy) wrote:
>
> Hi all,
>
> The SBI spec defines a standard set of error codes, which SBI
> functions can
> return in case of failure (or success). Each function defined in the
> SBI spec
> also defines which error codes it returns in which cases.
>
> My question is:
> Can an SBI implementation deviate from these error codes or do the
> SBI ecalls
> have to return the standardized error codes, no more, no less?
> If they can, in which way? Do they have to implement the standard
> error codes
> for the listed cases but can return additional error codes for other
> non-specified cases?
>
> I'm talking only about the standardized functions. Functions in the
> vendor
> extension and proposed firmware extension could of course do
> whatever they
> want.
>
> Btw. I think we should mention in the riscv-sbi-doc repo, that this
> ML is the place to discuss SBI.
> (It is, right?)
>
> - Daniel
Yes, my thinking, too. I created a PR with my proposed additions to the
spec: https://github.com/riscv/riscv-sbi-doc/pull/51
Inline here also:
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. Cases unaccounted for by the
specification should use `SBI_ERR_FAILED` and be added in the next
version of the SBI specification.
Custom SBI calls defined in a vendor or firmware extension can return
custom error codes, however it is recommended that they use the standard
error codes when appropriate.
- Daniel
|
|
|
Schaefer, Daniel Helmut (DualStudy) <daniel.schaefer@...>
Hi Abner and Jonathan,
you're right. I included that sentence to give the implementor a
way out,
if the spec doesn't cover a particular case. Now I understand that
this would
be result in very unpredictable behaviour and invite misuse.
If the spec if broken, we need to fix it.
Has anybody thought about an SBI testing tool to make sure an
implementation
conforms to the spec? Should be doable by hooking QEMU.
Here's the updated text:
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.
Custom SBI calls defined in a vendor or firmware extension can
return
custom error codes, however it is recommended that they use
the standard
error codes when appropriate.
Another thought: We've got some uses of 'must', 'should', ... .
Should we add a reference to RFC2199 [1] and check whether we used
all of the
keywords correctly?
[1] https://tools.ietf.org/html/rfc2119
- Daniel
On 5/18/20 3:42 AM, Chang, Abner (HPS
SW/FW Technologist) wrote:
toggle quoted message
Show quoted text
Hi
Daniel,
It
is no necessary to mention that sentence, instead we should
well define the error codes returned from all sbi function,
as you said no more, no less.
that
says we shouldn’t have unaccounted cases with a unclear
error code defined in sbi function. The sbi function is not
just a guidance to sbi implementation, it could be also a
criteria for SBI testing tool to validate the error code
return from the implementation of sbi function.
Right?
Abner
Is it really necessary to include
"Cases unaccounted for by the specification should use
`SBI_ERR_FAILED` and be added in the next version of the
SBI specification." ? This empowers an implementation to
return ERR_FAILED whenever it doesn't feel like
executing a function. In the extreme case, you could
have an empty implementation that declared "function
unimplemented" to be a case that is unaccounted for by
the spec, and just returned failure for literally every
call. It also isn't clear to me how a supervisor is
meant to respond to getting one of these errors. Should
it retry until it gets success? Issue a kernel panic?
Something else?
On 5/17/20 5:20 PM, Jonathan Behrens
wrote:
> I'd argue that standard functions should only be
allowed to return the
> error codes specifically listed in their
descriptions (or
> SBI_ERR_INVALID_PARAM for invalid hart masks). It
makes it way easier
> for users of the API if they can know in advance
what errors could be
> returned. This is the way I interpreted the current
spec, though
> clarification might be worthwhile.
>
> Jonathan
>
> On Sun, May 17, 2020 at 7:36 AM Schaefer, Daniel
Helmut (DualStudy) wrote:
>
> Hi all,
>
> The SBI spec defines a standard set of error
codes, which SBI
> functions can
> return in case of failure (or success). Each
function defined in the
> SBI spec
> also defines which error codes it returns in
which cases.
>
> My question is:
> Can an SBI implementation deviate from these
error codes or do the
> SBI ecalls
> have to return the standardized error codes, no
more, no less?
> If they can, in which way? Do they have to
implement the standard
> error codes
> for the listed cases but can return additional
error codes for other
> non-specified cases?
>
> I'm talking only about the standardized
functions. Functions in the
> vendor
> extension and proposed firmware extension could
of course do
> whatever they
> want.
>
> Btw. I think we should mention in the
riscv-sbi-doc repo, that this
> ML is the place to discuss SBI.
> (It is, right?)
>
> - Daniel
Yes, my thinking, too. I created a PR with my proposed
additions to the
spec: https://github.com/riscv/riscv-sbi-doc/pull/51
Inline here also:
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. Cases
unaccounted for by the
specification should use `SBI_ERR_FAILED` and be added
in the next
version of the SBI specification.
Custom SBI calls defined in a vendor or firmware
extension can return
custom error codes, however it is recommended that they
use the standard
error codes when appropriate.
- Daniel
|
|
|
Jonathan Behrens <behrensj@...>
I'd be in favor of making sure our use of 'must', 'should', etc. are consistent with that RFC. I also noticed that there's some parts that probably belong in a non-normative conventions chapter. Stuff like "Every SBI function should prefer unsigned long as the data type..." is directed at spec authors, not implementors.
Jonathan
Hi Abner and Jonathan,
you're right. I included that sentence to give the implementor a
way out,
if the spec doesn't cover a particular case. Now I understand that
this would
be result in very unpredictable behaviour and invite misuse.
If the spec if broken, we need to fix it.
Has anybody thought about an SBI testing tool to make sure an
implementation
conforms to the spec? Should be doable by hooking QEMU.
Here's the updated text:
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.
Custom SBI calls defined in a vendor or firmware extension can
return
custom error codes, however it is recommended that they use
the standard
error codes when appropriate.
Another thought: We've got some uses of 'must', 'should', ... .
Should we add a reference to RFC2199 [1] and check whether we used
all of the
keywords correctly?
[1] https://tools.ietf.org/html/rfc2119
- Daniel
On 5/18/20 3:42 AM, Chang, Abner (HPS
SW/FW Technologist) wrote:
Hi
Daniel,
It
is no necessary to mention that sentence, instead we should
well define the error codes returned from all sbi function,
as you said no more, no less.
that
says we shouldn’t have unaccounted cases with a unclear
error code defined in sbi function. The sbi function is not
just a guidance to sbi implementation, it could be also a
criteria for SBI testing tool to validate the error code
return from the implementation of sbi function.
Right?
Abner
Is it really necessary to include
"Cases unaccounted for by the specification should use
`SBI_ERR_FAILED` and be added in the next version of the
SBI specification." ? This empowers an implementation to
return ERR_FAILED whenever it doesn't feel like
executing a function. In the extreme case, you could
have an empty implementation that declared "function
unimplemented" to be a case that is unaccounted for by
the spec, and just returned failure for literally every
call. It also isn't clear to me how a supervisor is
meant to respond to getting one of these errors. Should
it retry until it gets success? Issue a kernel panic?
Something else?
On 5/17/20 5:20 PM, Jonathan Behrens
wrote:
> I'd argue that standard functions should only be
allowed to return the
> error codes specifically listed in their
descriptions (or
> SBI_ERR_INVALID_PARAM for invalid hart masks). It
makes it way easier
> for users of the API if they can know in advance
what errors could be
> returned. This is the way I interpreted the current
spec, though
> clarification might be worthwhile.
>
> Jonathan
>
> On Sun, May 17, 2020 at 7:36 AM Schaefer, Daniel
Helmut (DualStudy) wrote:
>
> Hi all,
>
> The SBI spec defines a standard set of error
codes, which SBI
> functions can
> return in case of failure (or success). Each
function defined in the
> SBI spec
> also defines which error codes it returns in
which cases.
>
> My question is:
> Can an SBI implementation deviate from these
error codes or do the
> SBI ecalls
> have to return the standardized error codes, no
more, no less?
> If they can, in which way? Do they have to
implement the standard
> error codes
> for the listed cases but can return additional
error codes for other
> non-specified cases?
>
> I'm talking only about the standardized
functions. Functions in the
> vendor
> extension and proposed firmware extension could
of course do
> whatever they
> want.
>
> Btw. I think we should mention in the
riscv-sbi-doc repo, that this
> ML is the place to discuss SBI.
> (It is, right?)
>
> - Daniel
Yes, my thinking, too. I created a PR with my proposed
additions to the
spec: https://github.com/riscv/riscv-sbi-doc/pull/51
Inline here also:
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. Cases
unaccounted for by the
specification should use `SBI_ERR_FAILED` and be added
in the next
version of the SBI specification.
Custom SBI calls defined in a vendor or firmware
extension can return
custom error codes, however it is recommended that they
use the standard
error codes when appropriate.
- Daniel
|
|
|
On Mon, 2020-05-18 at 14:05 +0200, Schaefer, Daniel Helmut (DualStudy) wrote: Hi Abner and Jonathan,
you're right. I included that sentence to give the implementor a way
out,
if the spec doesn't cover a particular case. Now I understand that
this would
be result in very unpredictable behaviour and invite misuse.
If the spec if broken, we need to fix it.
Has anybody thought about an SBI testing tool to make sure an
implementation
conforms to the spec? Should be doable by hooking QEMU.
Yeah. That would be useful. Patches are welcome!! Here's the updated text:
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.
As discussed in the OpenSBI mailing list, this might not be possible always. Supervisor software should decide whether it wants to hang the system or continue in case of an unknown error (i.e. SBI_ERR_FAILED). Custom SBI calls defined in a vendor or firmware extension can
return
custom error codes, however it is recommended that they use the
standard
error codes when appropriate.
Another thought: We've got some uses of 'must', 'should', ... .
Should we add a reference to RFC2199 [1] and check whether we used
all of the
keywords correctly?
[1] https://tools.ietf.org/html/rfc2119
Yup. That would be nice. - Daniel
On 5/18/20 3:42 AM, Chang, Abner (HPS SW/FW Technologist) wrote:
Hi Daniel,
It is no necessary to mention that sentence, instead we should well
define the error codes returned from all sbi function, as you said
no more, no less.
that says we shouldn’t have unaccounted cases with a unclear error
code defined in sbi function. The sbi function is not just a
guidance to sbi implementation, it could be also a criteria for SBI
testing tool to validate the error code return from the
implementation of sbi function.
Right?
Abner
From: Jonathan Behrens [mailto:behrensj@...]
Sent: Monday, May 18, 2020 5:56 AM
To: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>
Cc: tech-unixplatformspec@...; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] SBI Error codes
Is it really necessary to include "Cases unaccounted for by the
specification should use `SBI_ERR_FAILED` and be added in the next
version of the SBI specification." ? This empowers an
implementation to return ERR_FAILED whenever it doesn't feel like
executing a function. In the extreme case, you could have an empty
implementation that declared "function unimplemented" to be a case
that is unaccounted for by the spec, and just returned failure for
literally every call. It also isn't clear to me how a supervisor is
meant to respond to getting one of these errors. Should it retry
until it gets success? Issue a kernel panic? Something else?
Jonathan
On Sun, May 17, 2020 at 2:21 PM Daniel Schaefer <
daniel.schaefer@...> wrote:
On 5/17/20 5:20 PM, Jonathan Behrens wrote:
I'd argue that standard functions should only be allowed to return the
error codes specifically listed in their descriptions (or
SBI_ERR_INVALID_PARAM for invalid hart masks). It makes it way easier
for users of the API if they can know in advance what errors could be
returned. This is the way I interpreted the current spec, though
clarification might be worthwhile.
Jonathan
On Sun, May 17, 2020 at 7:36 AM Schaefer, Daniel Helmut (DualStudy) wrote:
Hi all,
The SBI spec defines a standard set of error codes, which
SBI
functions can
return in case of failure (or success). Each function defined in the
SBI spec
also defines which error codes it returns in which cases.
My question is:
Can an SBI implementation deviate from these error codes or do the
SBI ecalls
have to return the standardized error codes, no more, no less?
If they can, in which way? Do they have to implement the standard
error codes
for the listed cases but can return additional error codes for other
non-specified cases?
I'm talking only about the standardized functions. Functions in the
vendor
extension and proposed firmware extension could of course do
whatever they
want.
Btw. I think we should mention in the riscv-sbi-doc repo, that this
ML is the place to discuss SBI.
(It is, right?)
- Daniel Yes, my thinking, too. I created a PR with my proposed additions
to the
spec: https://github.com/riscv/riscv-sbi-doc/pull/51
Inline here also:
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. Cases unaccounted for by
the
specification should use `SBI_ERR_FAILED` and be added in the
next
version of the SBI specification.
Custom SBI calls defined in a vendor or firmware extension can
return
custom error codes, however it is recommended that they use the
standard
error codes when appropriate.
- Daniel -- Regards, Atish
|
|
|
