search

riscvarchive / riscv-platform-specs

RISC-V Profiles and Platform Specification
Creative Commons Attribution 4.0 International
112 stars 39 forks source link

Update Intro and Provide Clarity of Motivation for OS-A #75

Open adurbin-rivos opened 2 years ago

adurbin-rivos commented 2 years ago

Add in verbiage largely cribbed from platform policy to set goals and movitation in approach. Articulate the expectation of OS-A.

Not meant for merge. This is to start a discussion.

darius-bluespec commented 2 years ago

Since this is the first attempt to define a RISC-V platform, we are in a unique position to define both (1) what a platform is, and (2) the first one (or few) platforms themselves. I think the introduction needs to provide a clear definition and scope for both (1) and (2).

For example, with respect platforms generally:

A RISC-V Platform is a specification of one or more standard execution environments (for example, at M, S, and/or U mode). A Platform references Profiles (ISA extensions), and also defines other necessary requirements such as peripherals and environment services such that compatible implementations and executables may be interchangeable. Each Platform Specification will define a scope to convey the target applicability of the Platform.

And with respect to the OS-A platform:

The OS-A Platform specifies an S-mode execution environment sufficient for binary compatibility in booting general purpose rich operating systems (such as Ubuntu, RedHat Enterprise Linux, or FreeBSD).

I would also hope that the introduction could be more clear about terminology used.

For example, software and hardware are used in various different, conflicting ways. I would recommend avoiding the use of those terms in most or all cases, using alternative or more specific terms ("platform implementation", "application software", "the operating system", etc.) as appropriate. With respect execution environments, I would suggesting using "implementation" instead of "hardware" for the environment provider, and "executable" instead of "software" for the environment consumer.

There was a suggestion on the mailing list to use RFC 2119 terminology. I think we should either incorporate that, or else be clear (with definitions) with terms like "should", "recommended", and "optional". The Profile specification also defines useful terminology that might be worthwhile to incorporate.

It might also be useful to add discussion (non-normative) text to convey some of the non-goals of platforms in general and/or of specific platforms. For example, that the platform specification is agnostic to implementation technology (simulation, emulation, trap-and-emulate, traditional "real" hardware). Or, for the OS-A Platform at least, given that a device tree and/or ACPI is required, parameters or other details that can be conveyed through such a mechanism should not be mandated in the Platform itself.

kumarsankaran commented 2 years ago

@adurbin-rivos Agree with your patch suggestions. @darius-bluespec Agree with your additional comments as well. @adurbin-rivos Do you want to update your patch with the additional commentary so we can get these changes in and close this issue? I know we are moving some of these to the OS-A SEE spec. So it will be good to get these changes in so we have a baseline when we pick this up later.

adurbin-rivos commented 2 years ago

@kumarsankaran I think the platform stuff is going to split across new Platform and OS-A SEE so I'm not sure it's necessary to merge. We are going to tease these apart anyway. Let's just keep this request around for now for the content in order to seed OS-A SEE. Then we can drop it. Or if you want to land it first, we can. However, we haven't incorporated Darius's commentary yet either. Your call.

kumarsankaran commented 2 years ago

@adurbin-rivos OK fair enough. Let's keep this PR open for now. We can revisit after we complete definition of the OS-A SEE spec and pull this content into OS-A platforms as needed.