1. Tech-Unixplatformspec
  2. Topics

[RISC-V][tech-os-a-see] OS-A SEE Proposed Charter

Darius Rad
 

On Tue, Apr 12, 2022 at 09:43:43AM -0700, Aaron Durbin wrote:
On Fri, Apr 8, 2022 at 3:45 AM <darius@...> wrote:
On Mon, Apr 04, 2022 at 08:49:28AM -0600, Aaron Durbin wrote:
On Fri, Mar 25, 2022 at 7:25 AM <darius@...> wrote:


- The RISC-V Privileged Architecture treats the SEE as "concrete
instances of components implementing the interfaces", whereas the
proposed charter is somewhat more vague. Obviously that
definition is
what we are discussing here, but generally it should be clear
whether
the SEE is (1) one or a set of interfaces, (2) a reference or
abstract
implementation, or (3) any one of a number of specific
implementations.
It would be (3). I'll adjust to try to make that clearer. Feel free to
provide specific suggestions as well to the prose.
Maybe I am missing some nuance, but what I keep going back to is that it
seems the very thing you are describe is exactly the SBI as defined in the
RISC-V Privileged Architecture. Unfortunate terminology aside, to me it
seems like the ideal term is SBI and is clearly described in the Privileged
Architecture.

A specification typically defines the interfaces, as the concrete instance
is up to each implementation. I guess I don't understand how we would
define the *environment* (SEE) if not by the *interface* (SBI), and if we
are defining the *interface*, is that not SBI (per the priv spec
definition)?

I think I answered your original question incorrectly (or I misunderstood
what (3) was suggesting. I was suggesting (3) could be achieved by
adhering/using (1).

W.r.t. to SBI vs SEE, I appreciate the attention to detail, Darius. You are
correct that the current privilege spec calls these abstract concepts out
in that specific way. FWIW, the HBI and HEE as currently detailed in the
specification are not reality in how the H extension has been defined.
I haven't been following the H extension closely, and was not aware the
HBI/HEE terms have suffered the same fate. This is one of those things
that makes it hard to convince people to take RISC-V seriously; when we
can't even be consistent with terms that we invent.

How things have progressed in RISC-V has caused a naming a collision. We
have the abstract SBI concept from the current incarnation of the ISA
manual, and we have the SBI specification. The latter does fully define the
interfaces a supervisor implementation requires in the world of an OS-A
rich OS. That includes other entities, e.g. UEFI, DeviceTree bindings,
ACPI, etc in addition to some pieces of the SBI specification.

So what should we call this? SBI is already overloaded. Would could tack on
an 'I' for interface and make it SEEI, but there isn't a pure 'SBI' name
that one can take advantage of because that ship has already sailed.
I was hoping that since the SBI specification had not been ratified that it
could be renamed to be more consistent with prior usage of that term. But
if, as you say, that ship has sailed, then I'll drop it.

SEEI seems reasonable, or perhaps SEI for Supervisor Environment Interface.
I don't have a strong opinion about the term that is used, other than it
*not* be SEE, so we don't perpetuate this bad habit of reusing specific
terms with explicitly different meanings. And that we define the term
clearly at whatever point we start using it (i.e., in the charter, if the
charter uses it).

- SBI is used in the RISC-V Privileged Architecture as the entirety
of the interface between the SEE and the operating system.
Separately, we have this RISC-V thing called SBI (of which OpenSBI
is an implementation) which encapsulates some, but not all, of
that functionality. For example, memory mapped peripherals are
not part of the OpenSBI type of SBI, but appear to be covered by
the other style SBI.
It's an unfortunate reuse of terms that mean different things. It's also
abstract in that current implementations/usage does not rely on SBI spec
as
its only dependency in booting the kernel.
I don't follow that second sentence, could you elaborate?
The kernels don't only use SBI, as in the SBI specification, to boot and
run for an OS-A machine. As noted above other specs and dependencies exist
beyond SBI when SBI mean 'SBI specification'.
I think I understand what you are saying now, and I think that was roughly
the same point I was trying to make, in the context of advocating for a
single consistent use of the term SBI (for one usage only). In any case, I
guess we're just accepting that the term SBI is a confusing mess.

The proposed charter seems to be unclear on this point. It says "focus
will be on the interfaces between the SEE and the hosted environment",
which suggests the lower interface to me. However, it also refers to
binary compatible operating systems, which suggests the upper
interface.
The target of SEE is for entities building binary compatible operating
systems. i.e. One could take a distribution from any provider and boot
said
distribution on a compatible RISC-V implementation. I adjusted the
verbiage
some to hopefully make that clearer w.r.t. intent.
Maybe I'm missing something, because I am envisioning that the SEE *is* the
firmware or hosted environment. I don't understand what these interfaces
would be between.
SEE is the supervisor's environment and how the supervisor interacts w/ the
firmware or hosted environment is what we are attempting to nail down and
define. I don't think there are any interfaces between or if there are then
that would be out of the scope of this endeavor.
Perhaps instead of "The focus will be on the interfaces between the SEE and
the hosted environment", use "The focus will be on the interfaces between
the operating system and the SEE (through which the operating system may,
for example, access services provided by the firmware or otherwise)".

// darius
Aaron Durbin
 



On Fri, Apr 15, 2022 at 6:56 AM <darius@...> wrote:
On Tue, Apr 12, 2022 at 09:43:43AM -0700, Aaron Durbin wrote:
> On Fri, Apr 8, 2022 at 3:45 AM <darius@...> wrote:
> > On Mon, Apr 04, 2022 at 08:49:28AM -0600, Aaron Durbin wrote:
> > > On Fri, Mar 25, 2022 at 7:25 AM <darius@...> wrote:
> > >
> > > >
> > > >   - The RISC-V Privileged Architecture treats the SEE as "concrete
> > > >     instances of components implementing the interfaces", whereas the
> > > >     proposed charter is somewhat more vague.  Obviously that
> > definition is
> > > >     what we are discussing here, but generally it should be clear
> > whether
> > > >     the SEE is (1) one or a set of interfaces, (2) a reference or
> > abstract
> > > >     implementation, or (3) any one of a number of specific
> > implementations.
> > > >
> > >
> > > It would be (3). I'll adjust to try to make that clearer. Feel free to
> > > provide specific suggestions as well to the prose.
> > >
> >
> > Maybe I am missing some nuance, but what I keep going back to is that it
> > seems the very thing you are describe is exactly the SBI as defined in the
> > RISC-V Privileged Architecture.  Unfortunate terminology aside, to me it
> > seems like the ideal term is SBI and is clearly described in the Privileged
> > Architecture.
> >
> > A specification typically defines the interfaces, as the concrete instance
> > is up to each implementation.  I guess I don't understand how we would
> > define the *environment* (SEE) if not by the *interface* (SBI), and if we
> > are defining the *interface*, is that not SBI (per the priv spec
> > definition)?
> >
> >
> I think I answered your original question incorrectly (or I misunderstood
> what (3) was suggesting. I was suggesting (3) could be achieved by
> adhering/using (1).
>
> W.r.t. to SBI vs SEE, I appreciate the attention to detail, Darius. You are
> correct that the current privilege spec calls these abstract concepts out
> in that specific way. FWIW, the HBI and HEE as currently detailed in the
> specification are not reality in how the H extension has been defined.
>

I haven't been following the H extension closely, and was not aware the
HBI/HEE terms have suffered the same fate.  This is one of those things
that makes it hard to convince people to take RISC-V seriously; when we
can't even be consistent with terms that we invent.

> How things have progressed in RISC-V has caused a naming a collision. We
> have the abstract SBI concept from the current incarnation of the ISA
> manual, and we have the SBI specification. The latter does fully define the
> interfaces a supervisor implementation requires in the world of an OS-A
> rich OS. That includes other entities, e.g. UEFI, DeviceTree bindings,
> ACPI, etc in addition to some pieces of the SBI specification.
>
> So what should we call this? SBI is already overloaded. Would could tack on
> an 'I' for interface and make it SEEI, but there isn't a pure 'SBI' name
> that one can take advantage of because that ship has already sailed.
>

I was hoping that since the SBI specification had not been ratified that it
could be renamed to be more consistent with prior usage of that term.  But
if, as you say, that ship has sailed, then I'll drop it.

SEEI seems reasonable, or perhaps SEI for Supervisor Environment Interface.
I don't have a strong opinion about the term that is used, other than it
*not* be SEE, so we don't perpetuate this bad habit of reusing specific
terms with explicitly different meanings.  And that we define the term
clearly at whatever point we start using it (i.e., in the charter, if the
charter uses it).

Both of those sound reasonable to me. I didn't modify the charter yet as I'd like to hear from others on this list w/ their opinion. I can make the change as required subsequently.
 

> > > >   - SBI is used in the RISC-V Privileged Architecture as the entirety
> > > >     of the interface between the SEE and the operating system.
> > > >     Separately, we have this RISC-V thing called SBI (of which OpenSBI
> > > >     is an implementation) which encapsulates some, but not all, of
> > > >     that functionality.  For example, memory mapped peripherals are
> > > >     not part of the OpenSBI type of SBI, but appear to be covered by
> > > >     the other style SBI.
> > > >
> > >
> > > It's an unfortunate reuse of terms that mean different things. It's also
> > > abstract in that current implementations/usage does not rely on SBI spec
> > as
> > > its only dependency in booting the kernel.
> > >
> >
> > I don't follow that second sentence, could you elaborate?
> >
>
> The kernels don't only use SBI, as in the SBI specification, to boot and
> run for an OS-A machine. As noted above other specs and dependencies exist
> beyond SBI when SBI mean 'SBI specification'.
>

I think I understand what you are saying now, and I think that was roughly
the same point I was trying to make, in the context of advocating for a
single consistent use of the term SBI (for one usage only).  In any case, I
guess we're just accepting that the term SBI is a confusing mess.

> > > > The proposed charter seems to be unclear on this point.  It says "focus
> > > > will be on the interfaces between the SEE and the hosted environment",
> > > > which suggests the lower interface to me.  However, it also refers to
> > > > binary compatible operating systems, which suggests the upper
> > interface.
> > > >
> > >
> > > The target of SEE is for entities building binary compatible operating
> > > systems. i.e. One could take a distribution from any provider and boot
> > said
> > > distribution on a compatible RISC-V implementation. I adjusted the
> > verbiage
> > > some to hopefully make that clearer w.r.t. intent.
> > >
> >
> > Maybe I'm missing something, because I am envisioning that the SEE *is* the
> > firmware or hosted environment.  I don't understand what these interfaces
> > would be between.
> >
>
> SEE is the supervisor's environment and how the supervisor interacts w/ the
> firmware or hosted environment is what we are attempting to nail down and
> define. I don't think there are any interfaces between or if there are then
> that would be out of the scope of this endeavor.
>

Perhaps instead of "The focus will be on the interfaces between the SEE and
the hosted environment", use "The focus will be on the interfaces between
the operating system and the SEE (through which the operating system may,
for example, access services provided by the firmware or otherwise)".

I adjusted the language, however I used 'its SEE' instead 'the SEE' to hopefully convey that the kernel/OS is residing within the SEE for itself -- not some other entity.



// darius

1 - 2 of 2