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