Re: Partial summary of potential Embedded-2022 platform spec discussion


atishp@...
 

On Tue, 2021-02-02 at 19:33 +0100, Philipp Tomsich wrote:
Linux-2022 is just working title... and we expect the final name to
be more neutral.
Calling it “rich OS” didn’t really work to convey the direction to
the audience.
I agree. I am also not sure calling embedded-2022 is a good idea
either. That may confuse outside folks to think that it is meant for
embedded Linux. Al had a better suggestion about the naming.
The specification can be called as Operating System platform
specification (OSPS).

How about this ?

OSPS2022-L0 - targets micro-controllers booting RTOS (zephyr, FreeRTOS
etc)

OSPS2022-L1 - targets hardware capable of booting rich OS such as
Unix/Windows

We will never have more than two levels but each specification will
evolve at 2 years cadence & different version numbers. For example:

The next version of the specifications will be called

OSPS2024-L0 & OSPS2021-L1

Any incremental updates will be just have a minor number versioning.

The Linux name was chosen to have concepts such from distros to
building from source in scope... we’ve always tried to be vocal that
this platform needs to address at least the *BSD variants and
(possibly) rich RTOSes.

In the end, a name will just be a name.
At this early stage, the working title needs to help focus us on
real-world use cases and challenges...

Cheers,
Philipp.

On Tue 2. Feb 2021 at 19:15, Jonathan Behrens <behrensj@...>
wrote:
 Is there an assumption that the only OS kernels claiming
compliance with Linux-2022 will actually be versions of the Linux
kernel? Given the name, it seems like it would be kind of awkward
for a competitor to claim that

Jonathan

On Tue, Feb 2, 2021 at 12:57 PM Alistair Francis via
lists.riscv.org <alistair.francis=wdc.com@...> wrote:

On Tue, 2021-02-02 at 18:08 +0100, Philipp Tomsich wrote:
Greg & Richard,

On Tue, Feb 2, 2021 at 5:47 PM Greg Favor
<gfavor@...>
wrote:
On Tue, Feb 2, 2021 at 12:31 AM
<Richard.Newell@...>
wrote:
Hi Greg, et al;
 
We expect Krypto Scalar specification to be ratified this
year. 
It is a lightweight extension designed especially for
embedded
systems.  The Krypto TG recommends the “K” extension be at
least
an optional part of the RVx22 profiles.
This definitely falls under the purview of the profile specs,
not
the platform specs.  I suggest contacting Krste and Mark
about
this.  The effort to put together the profile specs is just
getting
started (but expected to complete in a couple of months).

Off-hand I would imagine that this extension _will_ be part
of one
or both profiles (and probably as optional).
I would hope that the profiles provide this at least as
optional.

I'm not clear what we mean here. For the embedded spec all
extensiosn
will be optional, that would include ratified, frozen draft and
vendour
extensions.

Alistair


On the platforms side, we will then build (at least for the
Linux-
2022 profile) on this by mandating runtime discovery and
support for
it.
The details on how this support can/will look are still
sketchy,
however the following assertions should remain unchanged:
 * OS kernels claiming compliance with Linux-2022 will have a
discovery mechanism (details are TBD; might be as simple as a
bootloader passing in a flag via the DTB) to detect if K-
support is
present in hardware. 
 * OS kernels claiming compliance with Linux-2022 will expose
the
availability of K-instructions to userspace applications (e.g.
auxval
or hwcaps).
 *  * OS kernels claiming compliance with Linux-2022 will be
able to
determine (from an ELF binary) if it contains K-instructions or
not —
and will only execute code requiring K-instructions if support
is
present.
In addition, we'd like to see some adoption of crypto
instructions
for the benefit of users:
 *  * OS kernels will be encouraged to make use of K-
instructions for
crypto operations in the kernel (e.g. networking-related).
 * OS distributions will be encouraged to provide optimized
support
(ifunc, additional DSOs) using K-instructions for crypto
operations
in userspace (e.g. in OpenSSL).
If the "will be encouraged" will be a non-binding
recommendation or
if we will add this to an additional "package" (that
implementations
can claim conformance to), is to be seen and should become
clearer by
April.

Philipp.




 
--
Regards,
Atish

Join tech-unixplatformspec@lists.riscv.org to automatically receive all group messages.