On Mon, 2020-11-23 at 11:53 +0100, Philipp Tomsich wrote:
On Sun, Nov 22, 2020 at 11:05 PM Al Stone <ahs3@...> wrote:
The following is a dramatically simplified introduction to the platform spec. This is the part that seemed to generate the least discussion, so in the interest of progress, I'm proposing just this part. In v2 of this proposal, there was a lot of discussion about profiles and platforms and spec goals that we still need to work out. However, if we can break things out into smaller, more bite-size chunks, like this one, perhaps we can make quicker progress -- hence this v3 proposal.
Now that we've solidified the terminology around profiles and platforms, too, it may make it easier to get moving on additional sections. My plan is to get this moving, then tackle the "definition of profiles" section, and then the "definition of platforms". Once we have those in place, we can take on the embedded Linux use case.
Signed-off-by: Al Stone <ahs3@...>
Reviewed-by: Philipp Tomsich <philipp.tomsich@...>
See below for comments and nitpicks.
------------------------------------------------------------------- ---- // SPDX-License-Identifier: CC-BY-4.0 // // introduction.adoc: provide an introduction to the document // // Provide a basic introduction to the overall document. //
# Introduction
This document is the RISC-V Profiles and Platform Specification (RVP2S).
This specification defines the hardware and firmware required to be able to install and use one or more operating environments (OEs) on a computing system built around the RISC-V Instruction Set Architecture (ISA). The intent is to capture the constraints necessary for hardware so that an operating environment can be assured it is compatible with that hardware, if it is in compliance with the specification.
For the purposes of this specification an _operating environment_ can range from a single application running on a bare metal system to a full scale server operating system (OS) running a Linux distribution on a commercial off-the shelf (COTS) system.
Constraints on the hardware and firmware comprising part of a platform are key to this specification. For example, an OS needs to be able to make some basic assumptions about the platform in order to boot; if there are too many variations possible, it becomes unmanageable for the OS vendor
The wording seems to directly contradict the wish to foster creativity and innovation; it would be better to clarify how these basic assumptions (e.g. IRQ controller) should only provide a baseline/fallback, but that advanced functionality can always be supported through runtime probing.
and could preclude using the platform at all. We would like to ensure this does not happen.
This specification also sets out any necessary constraints on the RISCV-V
typo: RISCV-V => RISC-V
Instruction Set Architecture (ISA) -- at all privilege levels -- that are required to provide a consistent and predictable environment for running operating systems.
The intent is to provide only the constraints necessary, and not to restrict creativity.
The structure of the document is straightforward. First, basic terminology is defined, in particular the terms _profile_ and _platform_ that form the basis for the structure of the rest of the specification. Second, the currently defined profiles are described, setting out the use of the RISC-V architecture in a processor. Third, the current defined platforms are described with specific hardware, firmware, and software requirements. And finally, checklists are provided in the appendices to make it easier to determine if a new system meets a given platform specification.
-- ciao, al ----------------------------------- Al Stone Software Engineer Red Hat, Inc. ahs3@... -----------------------------------
Apart from the typo Philipp pointed out, everything else looks good to me.
