profile
viewpoint

fintelia/fighterpilot 4

Arcade style combat flight simulator game

fintelia/acceleray 1

Simple GPU path tracer using OpenGL

fintelia/gfx_smaa 1

Use SMAA antialiasing in gfx-rs applications

fintelia/hash-bench 1

A benchmark of the creation time of Rust's standard library HashMaps

Derecho-Project/derecho-project.github.io 0

Source code for the GitHub Organization Page

fintelia/24game 0

A solver for the game 24.

fintelia/amethyst 0

Data-oriented and data-driven game engine written in Rust

fintelia/arr_macro 0

Initialize arrays with ease!

fintelia/binutils-gdb 0

Unofficial mirror of sourceware binutils-gdb repository. Updated daily.

push eventfintelia/terra

Jonathan Behrens

commit sha 9db286d5ed951c0d51c2cf19389f371cfd8239a3

Improve rshader, better heightmap resolution, and much more

view details

push time in 2 days

push eventfintelia/image

philippeitis

commit sha 05bef1797bf09b5be5d0d2db1050c0f4e5c8b86c

Specify size of fdct input to enable SIMD and bound elision

view details

philippeitis

commit sha bab63f1dbcab9e3dda02640a4dbc3425469fbeb6

Add block size to write_block signature. This allows the elision of bounds checking.

view details

philippeitis

commit sha a7998c205de96a4da12d448411a057ce4d7bc882

Split write_segment into write_segment and write_marker This allows us to get rid of data: Option<&[u8]> in write_segment, which makes a big difference for the overall code size and removes the necessary checks for whether data is Some() or None. This additionally removes the need to use byteorder::{BigEndian, WriteBytesExt}, by using to_be_bytes instead.

view details

HeroicKatora

commit sha fd21a14102d09ee63de47be1ec429a3b4e64bbcc

Merge pull request #1325 from philippeitis/patch-1 Add size information to function signatures, optimize BitWriter in jpeg

view details

Eli Lindsey

commit sha 4b7659ed19b71d82a1a378869788c7e28bd798d1

fix typo, 'present panics' -> 'prevent panics'

view details

HeroicKatora

commit sha 3739a8467e3df9b936ed4cddb495907da528820d

Merge pull request #1330 from elindsey/master fix typo, 'present panics' -> 'prevent panics'

view details

Tianyi Shi

commit sha 83080cd695cbba94adb9f386989b9815b9b7d7f3

fix unnecessary lazy evaluation this should make the code simpler, and a bit faster (creating a enum of 32 bits)

view details

Tianyi Shi

commit sha 8002484d04da7ebb9d3b8d40c4980022b9aebc4a

consistent syntax with line 147

view details

HeroicKatora

commit sha 6bee185141c36d52d3abd404897ac135e5a343bf

Merge pull request #1332 from TianyiShi2001/extension consistent syntax with line 147

view details

Tianyi Shi

commit sha 2b8bd97b4664336b9a3fadd0a856511f7471a64d

fix string_lit_as_bytes this is cleaner

view details

Tianyi Shi

commit sha 2adb91762324ae2574339e77150d937a4439af54

fix clone_on_copy an array is already `Copy`

view details

Eli Lindsey

commit sha d274eb3b3bcd6b23204fc25af4fd790e753d77c8

fix typo, 'present panics' -> 'prevent panics'

view details

Tianyi Shi

commit sha 830e01018a769e608a5550c4229c69e1cc3673e0

prevent copying

view details

Rasmus Kaj

commit sha df6e2ca94343b8238ddc930fe970655a3af55b8f

Provide scale method of JpegDecoder. Add a `scale(&mut self, requested_width, requested_height)` to `JpegDecoder`, exposing same functionality in `jpeg_decoder::Decoder`. Question: As it is allowed for this function to do nothing, maybe it should be added to trait `ImageDecoder`? If would be possibe to add a meaningfull implementation to any "progressive" format, such as png and gif, and it's ok to do nothing for other formats.

view details

HeroicKatora

commit sha 1bb3aad116e91c81e55dfef7404ea8a33d79d08a

Merge pull request #1336 from kaj/jpeg-scale Provide scale method of JpegDecoder.

view details

HeroicKatora

commit sha 1141216fe04efdd6d9cd3541c70cd2d3076be827

Merge pull request #1331 from TianyiShi2001/fix-clippy Fix clippy warnings

view details

HeroicKatora

commit sha 861ae834b97651c446d19dfb59498c7e4832c0e7

Merge pull request #1335 from TianyiShi2001/ts-quick-fix Reduce copying in src/png.rs

view details

Jonathan Behrens

commit sha 21640356fb5c6e2b28b5d99d448609cd0b98d437

Move image file encoders/decoders to codecs module

view details

Jonathan Behrens

commit sha af700d2675d35d8b2f59213566f0e4b0bf68b281

Merge pull request #1328 from fintelia/codecs-module Move image file encoders/decoders to codecs module

view details

Tianyi Shi

commit sha 6302fdc4779f3af0580df9eea76df627d7b038f7

deprecate hq; alias to color_quant

view details

push time in 2 days

push eventfintelia/image

Jonathan Behrens

commit sha 52965f08265083ec3af1ef10143d348ccd92ca63

Generate warnings when using old paths for codec module items

view details

push time in 6 days

PR opened image-rs/image

Generate warnings when using old paths for codec module items

This is unfortunately more verbose / error-prone than I would like, but this way users will actually see warnings when using the old paths for the codec modules.

+158 -52

0 comment

3 changed files

pr created time in 6 days

push eventfintelia/image

Jonathan Behrens

commit sha 2c082f1f69009fa5f670eeb844d6f368a21f90bf

Generate warnings when using old paths for codec module items

view details

push time in 6 days

create barnchfintelia/image

branch : codec-deprecation-warnings

created branch time in 6 days

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

push eventimage-rs/image

Jonathan Behrens

commit sha c42e897f5494c25bfff96e8c6167fb1f8d68e170

Deprecate clamp function This function can easily be implemented with an `if` statement. There is no need for it to be part of image's public API.

view details

Jonathan Behrens

commit sha db73b8724b7fac49fa896bfa598293dbc428e7b1

Merge pull request #1342 from fintelia/deprecate-clamp Deprecate clamp function

view details

push time in 9 days

PR merged image-rs/image

Deprecate clamp function

The clamp function can easily be implemented with an if statement. There is no need for it to be part of image's public API. Since the function is internally used by the crate, I added an implementation to our internal utils module and converted all instances to use that instead.

+19 -4

0 comment

6 changed files

fintelia

pr closed time in 9 days

PR opened image-rs/image

Deprecate clamp function

This function can easily be implemented with an if statement. There is no need for it to be part of image's public API. Since the function is internally used by the crate, I added an implementation to our internal utils module and converted all instances to use that instead.

+19 -4

0 comment

6 changed files

pr created time in 9 days

create barnchfintelia/image

branch : deprecate-clamp

created branch time in 9 days

push eventimage-rs/image

Jonathan Behrens

commit sha 21640356fb5c6e2b28b5d99d448609cd0b98d437

Move image file encoders/decoders to codecs module

view details

Jonathan Behrens

commit sha af700d2675d35d8b2f59213566f0e4b0bf68b281

Merge pull request #1328 from fintelia/codecs-module Move image file encoders/decoders to codecs module

view details

push time in 11 days

PR merged image-rs/image

Move image file encoders/decoders to codecs module

This PR moves all the modules for specific image file formats into a new codecs module. Due to https://github.com/rust-lang/rust/issues/47236 I don't think there is a way to show a deprecation notice to people still using the old path.

With this change, the modules section of the generated docs are now more reasonable:

+35 -29

0 comment

35 changed files

fintelia

pr closed time in 11 days

issue commentimage-rs/image

Bench `math::nq`

My inclination would be to deprecate the math::nq module and just point people to the color_quant crate.

TianyiShi2001

comment created time in 11 days

push eventfintelia/image

philippeitis

commit sha 05bef1797bf09b5be5d0d2db1050c0f4e5c8b86c

Specify size of fdct input to enable SIMD and bound elision

view details

philippeitis

commit sha bab63f1dbcab9e3dda02640a4dbc3425469fbeb6

Add block size to write_block signature. This allows the elision of bounds checking.

view details

philippeitis

commit sha a7998c205de96a4da12d448411a057ce4d7bc882

Split write_segment into write_segment and write_marker This allows us to get rid of data: Option<&[u8]> in write_segment, which makes a big difference for the overall code size and removes the necessary checks for whether data is Some() or None. This additionally removes the need to use byteorder::{BigEndian, WriteBytesExt}, by using to_be_bytes instead.

view details

HeroicKatora

commit sha fd21a14102d09ee63de47be1ec429a3b4e64bbcc

Merge pull request #1325 from philippeitis/patch-1 Add size information to function signatures, optimize BitWriter in jpeg

view details

Eli Lindsey

commit sha 4b7659ed19b71d82a1a378869788c7e28bd798d1

fix typo, 'present panics' -> 'prevent panics'

view details

HeroicKatora

commit sha 3739a8467e3df9b936ed4cddb495907da528820d

Merge pull request #1330 from elindsey/master fix typo, 'present panics' -> 'prevent panics'

view details

Tianyi Shi

commit sha 83080cd695cbba94adb9f386989b9815b9b7d7f3

fix unnecessary lazy evaluation this should make the code simpler, and a bit faster (creating a enum of 32 bits)

view details

Tianyi Shi

commit sha 8002484d04da7ebb9d3b8d40c4980022b9aebc4a

consistent syntax with line 147

view details

HeroicKatora

commit sha 6bee185141c36d52d3abd404897ac135e5a343bf

Merge pull request #1332 from TianyiShi2001/extension consistent syntax with line 147

view details

Tianyi Shi

commit sha 2b8bd97b4664336b9a3fadd0a856511f7471a64d

fix string_lit_as_bytes this is cleaner

view details

Tianyi Shi

commit sha 2adb91762324ae2574339e77150d937a4439af54

fix clone_on_copy an array is already `Copy`

view details

Eli Lindsey

commit sha d274eb3b3bcd6b23204fc25af4fd790e753d77c8

fix typo, 'present panics' -> 'prevent panics'

view details

Tianyi Shi

commit sha 830e01018a769e608a5550c4229c69e1cc3673e0

prevent copying

view details

Rasmus Kaj

commit sha df6e2ca94343b8238ddc930fe970655a3af55b8f

Provide scale method of JpegDecoder. Add a `scale(&mut self, requested_width, requested_height)` to `JpegDecoder`, exposing same functionality in `jpeg_decoder::Decoder`. Question: As it is allowed for this function to do nothing, maybe it should be added to trait `ImageDecoder`? If would be possibe to add a meaningfull implementation to any "progressive" format, such as png and gif, and it's ok to do nothing for other formats.

view details

HeroicKatora

commit sha 1bb3aad116e91c81e55dfef7404ea8a33d79d08a

Merge pull request #1336 from kaj/jpeg-scale Provide scale method of JpegDecoder.

view details

HeroicKatora

commit sha 1141216fe04efdd6d9cd3541c70cd2d3076be827

Merge pull request #1331 from TianyiShi2001/fix-clippy Fix clippy warnings

view details

HeroicKatora

commit sha 861ae834b97651c446d19dfb59498c7e4832c0e7

Merge pull request #1335 from TianyiShi2001/ts-quick-fix Reduce copying in src/png.rs

view details

Jonathan Behrens

commit sha 21640356fb5c6e2b28b5d99d448609cd0b98d437

Move image file encoders/decoders to codecs module

view details

push time in 11 days

issue commentimage-rs/image

Bench `math::nq`

Do we know if anyone is actually using math::nq?

TianyiShi2001

comment created time in 11 days

PullRequestReviewEvent

pull request commentimage-rs/image

Reduce copying in src/png.rs

Your understanding is mostly correct. For interlaced images, I believe png::Reader actually does support "row-by-row" reading, but the actual order that it outputs rows in is jumbled (something like 0, 4, 2, 6, 1, 3, 5, 7...). Since image::png::PngReader promises to produce rows in order, this isn't very helpful.

TianyiShi2001

comment created time in 11 days

PullRequestReviewEvent

push eventmit-pdos/ward

Jonathan Behrens

commit sha 60fc66dee74df5360815ba68307efd24eee9a7e7

Skip timer interrupts when single stepping with debugger

view details

Jonathan Behrens

commit sha 91e95b2209658231efdfae80de10e4f171a99712

Get attack working again

view details

Jonathan Behrens

commit sha 6e8ee6066d85ac93c19e68895e34e2cbf76a03d1

Some cleanup for spectrev2 attack code

view details

Jonathan Behrens

commit sha 4adb8313340d3b9d98e691bf2c076a77db960f9c

Run attack demo in the K-domain

view details

push time in 13 days

push eventmit-pdos/ward

Jonathan Behrens

commit sha 3af15fcd9e4c40d6fba101aa80cf97a3a52fab5f

Fix bug in pageinfo initialization

view details

push time in 13 days

PR opened image-rs/image

Streamline docs.rs documentation and move some content to README

Not super polished, but hopefully an improvement over the current text.

+95 -95

0 comment

2 changed files

pr created time in 14 days

create barnchfintelia/image

branch : readme-changes

created branch time in 14 days

pull request commentimage-rs/image

Deprecate compound input fn in favor of Reader

Using renaming imports would be an improvement, but I want to think through a bit more. I guess my concerns are:

  1. Discoverability: The generated docs are too cluttered, but despite being one of the most important types in the crate, io::Reader is particularly hidden.
  2. Code readability: Seeing Reader::new(...).decode() tells you almost nothing about what it being read. Even the io prefix doesn't make things more clear. Your suggestion of using renaming imports largely resolves this point.
  3. Consistency: Other names like ImageDecoder include the Image prefix in them. Probably the least important item.
HeroicKatora

comment created time in 14 days

push eventmit-pdos/ward

Jonathan Behrens

commit sha 19b25c9d6d23f4b7b7eeeadcd4fe2ef413fcb92e

Update README.md

view details

push time in 14 days

push eventfintelia/image

Jonathan Behrens

commit sha ee25197ddd1a301678502dddd114a6fea00878f4

Move image file encoders/decoders to codecs module

view details

push time in 14 days

PR opened image-rs/image

Move image file encoders/decoders to codecs module

This PR moves all the modules for specific image file formats into a new codecs module. Due to https://github.com/rust-lang/rust/issues/47236 I don't think there is a way to show a deprecation notice to people still using the old path.

With this change, the modules section of the generated docs are now more reasonable: image

+35 -29

0 comment

35 changed files

pr created time in 14 days

create barnchfintelia/image

branch : codecs-module

created branch time in 14 days

issue commentimage-rs/image

Add sponsor link in repo

I think the main question to address first is what the funding would be used for. Are there contributors who are interested in being funded to work on image-rs? If so, I see no reason not to indicate that somewhere so that they can connect with sponsors interested in funding development.

repi

comment created time in 14 days

pull request commentimage-rs/image

Deprecate compound input fn in favor of Reader

I'm very much in favor of deprecating these functions, but I also think we should rename io::Reader at the same time since it would be much harder to do later. (We should of course keep the old name as an alias for a while to have backwards compatibility).

My concern with the current name is that it is too generic. It only barely manages to avoid conflicting with the Read and BufReader names in stdlib, and the module scope doesn't disambiguate because the standard library also has an io module. Worse people commonly use std::io; so that they can disambiguate std::io::Error from other errors so they then can't also use image::io.

My preference would be to switch to calling it ImageReader and making the io module internal to the crate.

HeroicKatora

comment created time in 14 days

Pull request review commentimage-rs/jpeg-decoder

Make small perf refactors, clippy and grammar fixes

 fn compute_image(components: &[Component],                  output_size: Dimensions,                  is_jfif: bool,                  color_transform: Option<AdobeColorTransform>) -> Result<Vec<u8>> {-    if data.iter().any(|data| data.is_empty()) {-        return Err(Error::Format("not all components has data".to_owned()));+    if data.iter().any(std::vec::Vec::is_empty) {

nit: I don't think you need the std::vec:: part

okaneco

comment created time in 16 days

PullRequestReviewEvent

fork fintelia/efi-clang

Build UEFI applications with the Clang compiler and LLD linker.

fork in 16 days

Pull request review commentimage-rs/image

Make functions in jpeg/encoder.rs more idiomatic, clean up todos

 impl<'a, W: Write> JpegEncoder<'a, W> {             200 - scale * 2         }; -        let mut tables = Vec::new();-        let scale_value = |&v: &u8| {-            let value = (u32::from(v) * scale + 50) / 100;+        let mut tables = vec![STD_LUMA_QTABLE.clone(), STD_CHROMA_QTABLE.clone()];+        let scale_value = |v: &mut u8| {+            let value = (u32::from(*v) * scale + 50) / 100; -            clamp(value, 1, u32::from(u8::max_value())) as u8+            *v = clamp(value, 1, u32::from(u8::max_value())) as u8;         };-        tables.extend(STD_LUMA_QTABLE.iter().map(&scale_value));-        tables.extend(STD_CHROMA_QTABLE.iter().map(&scale_value));+        tables[0].iter_mut().for_each(scale_value);+        tables[1].iter_mut().for_each(scale_value);

Mostly just removing duplication/making the code more concise. There's lots of possible variations, but one option would be something like:

let tables = vec![STD_LUMA_QTABLE.clone(), STD_CHROMA_QTABLE.clone()].into_iter().map(|t|t.iter_mut().for_each(|v|{
        *v = clamp((u32::from(*v) * scale + 50) / 100, 1, u32::from(u8::max_value())) as u8;
})).collect();
philippeitis

comment created time in 16 days

PullRequestReviewEvent

Pull request review commentimage-rs/image

Make functions in jpeg/encoder.rs more idiomatic, clean up todos

 impl<'a, W: Write> JpegEncoder<'a, W> {             200 - scale * 2         }; -        let mut tables = Vec::new();-        let scale_value = |&v: &u8| {-            let value = (u32::from(v) * scale + 50) / 100;+        let mut tables = vec![STD_LUMA_QTABLE.clone(), STD_CHROMA_QTABLE.clone()];+        let scale_value = |v: &mut u8| {+            let value = (u32::from(*v) * scale + 50) / 100; -            clamp(value, 1, u32::from(u8::max_value())) as u8+            *v = clamp(value, 1, u32::from(u8::max_value())) as u8;         };-        tables.extend(STD_LUMA_QTABLE.iter().map(&scale_value));-        tables.extend(STD_CHROMA_QTABLE.iter().map(&scale_value));+        tables[0].iter_mut().for_each(scale_value);+        tables[1].iter_mut().for_each(scale_value);

This block of code could probably be cleaner with a bit of refactoring. Not a huge deal, but might be worth doing if it is being changed anyway

philippeitis

comment created time in 17 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventmit-pdos/ward

Jonathan Behrens

commit sha 323b93f34074eadb5cdb371441a8b17833b170e9

Remove a bunch of unused floating point builtins

view details

Jonathan Behrens

commit sha add95988c070f5703422517b49a6f2e4b48604ee

Remove libcxx random number generation

view details

Jonathan Behrens

commit sha ca3e3021f0b298c1f344cf0c44286fa765060106

Delete libcxx floating point functionality

view details

Jonathan Behrens

commit sha 028a9b8cfd40b452a0c53522366b463b45c5d57d

C('/') isn't a valid character code

view details

Jonathan Behrens

commit sha 13a4dcc481fbe5da3976b4cc0dfb5d5e90974653

Fix warning in __bswap64

view details

Jonathan Behrens

commit sha 92a55dd85f238a445caa1483ad0d2132fdaa8324

Remove demangling code involving floats

view details

push time in 18 days

push eventmit-pdos/ward

Jonathan Behrens

commit sha d81ba8da26e638e0a929f2b860b5875cf10807e9

Update 'time' and 'param' binaries

view details

Jonathan Behrens

commit sha a1304da14bfbaa420a71b27971f63267a2015b6d

Make some gc and vfs state qvisible

view details

Jonathan Behrens

commit sha 752b3a212801c4c4284fa97c08ff682b95d37274

Make some filesystem state qvisible

view details

push time in 18 days

push eventmit-pdos/ward

Jonathan Behrens

commit sha 12a429096e628ad164bcd4b85245c7e0a34294d8

Fix a kernel panic

view details

Jonathan Behrens

commit sha 1b14cb7e8f9bf62d949c279b8a7c66796e13b6e3

Detect cases in scheduler where world barriers is required

view details

push time in 19 days

issue commentimage-rs/image

Library wide memory limits

Also TIFF tags are only 16-bits, so even if the image contained every possible tag (most of which aren't even defined...) the hashtable would only take a few megabytes.

birktj

comment created time in 19 days

issue commentimage-rs/image

Library wide memory limits

@birktj how does your design deal with adding additional strict limits later? Wouldn't decoders have to know about the change or else they'd silently ignore the new limits?

birktj

comment created time in 19 days

issue commentimage-rs/image

Content based file type guessing

The io::Reader interface supports guessing the format based on the initial bytes of the file. Is that what you are looking for?

jerry73204

comment created time in 20 days

push eventmit-pdos/ward

Jonathan Behrens

commit sha afce26ffb777073e8065dee9b7cffe063981e42e

Output less

view details

push time in 20 days

push eventmit-pdos/ward

Jonathan Behrens

commit sha 05042478764667787bdb043faee701583da9d696

Re-enable benchbarriers

view details

push time in 21 days

push eventmit-pdos/ward

Jonathan Behrens

commit sha 695277d4f39b339e124fbf143e9a185f9650980d

Handle (but ignore) mouse input This resolves the lockup issue on the X1 Carbon, which was caused by touchpad input blocking all future keyboard events.

view details

Jonathan Behrens

commit sha f95647dc08da89a9aa047e28c80eaf276c9d08bb

Remove workaround for X1 Carbon bug

view details

push time in 21 days

startedDTolm/VkFFT

started time in 22 days

Pull request review commentimage-rs/image

Release notes for 0.23.10

 Rust image aims to be a pure-Rust implementation of various popular image format  ## Changes +### Version 0.23.10++- Added AVIF encoding capabilities using the `ravif` crate. Please note that+  the feature targets the stable compiler and is not enabled by default.

stable -> latest stable

HeroicKatora

comment created time in 24 days

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentimage-rs/image

Release notes for 0.23.10

Perhaps "requires latest stable rustc"?

HeroicKatora

comment created time in 24 days

pull request commentimage-rs/image

Release notes for 0.23.10

There's some references to the stable compiler. Do those really not work if you compile with nightly? I thought anything that worked with stable was supposed to work with subsequent nightlies, but perhaps I'm misunderstanding?

HeroicKatora

comment created time in 24 days

PullRequestReviewEvent

push eventmit-pdos/ward

Jonathan Behrens

commit sha 05b67ab1f5d46a38179f607e623294e4ffc5ecd6

Fix LWIP macro issue

view details

push time in a month

push eventmit-pdos/ward

Jonathan Behrens

commit sha e4e002d1e7198cf7b7e97d2dd577a076b53d0c85

Fix Makefile handling of microcode files

view details

Jonathan Behrens

commit sha 0fe00c3251027f30c9a8ad3e362643114f17ad7a

Print old microcode revision during update

view details

Jonathan Behrens

commit sha 8c0a729204988c5279d2dcc2f08e4ef62b5a5bdd

Have lebench report average instead of best cycle counts

view details

push time in a month

Pull request review commentriscv/riscv-platform-specs

Housekeeping

+# RISC-V Operating System Platform Specification+:author: RISC-V Platform Specification Task Group+:email: tech-unixplatformspec@lists.riscv.org+:revnumber: 0.1.0-draft+:revdate: September 2020+:revremark: Initial version.+:doctype: book+:sectnums:+:toc: macro++// Table of Contents+toc::[]++// Overall document copyrights and licensing+include::licensing.adoc[]++// Document contributors+include::contributors.adoc[]++// Changelog+include::changelog.adoc[]++// Begin the really interesting parts of the document+## Introduction++This document is the RISC-V Operating System Platform Specification+(OSPS).  This specification defines the hardware and firmware+required to be able to install and use one or more operating systems on a+platform built around the RISC-V Instruction Set Architecture (ISA).+The intent is to set out the constraints necessary+for a hardware platform so that an operating system can be assured+it is compatible with that platform, if the platform is in compliance+with this specification.++This specification also sets out the constraints on the+RISCV-V Instruction Set Architecture (ISA) -- at all privilege +levels -- that are needed to provide a consistent and predictable+environment for running these operating systems.++The OSPS sets out the constraints on platforms as _use cases_.  Each+use case specifies a particular combination of hardware platform+and operating system to be used in specific environments.  For example,+the general purpose computing use case specifies the expected hardware+and firmware for systems such as commercial laptop, desktop or server+computers; these use cases generally match acknowledged market+segments possible for RISC-V based platforms.++In order for a platform to be compliant with OSPS, it must be compliant+with a specific use case.  That may allow it to be compliant with other+use cases, but it is recommended that a platform have one specific target+to start from.  For any given use case, all mandatory requirements must be+implemented in the platform.  Optional requirements may or may not be+implemented on any given platform; if such a requirement+could cause the platform to behave differently when not implemented,+a fallback position is specified that must be implemented.++Over time, it is expected that each use case will see a series of+revisions.  Under ideal circumstances, a platform will be compliant+with the most recent version of any use case specification.  When a+platform indicates it is compliant with the OSPS, it should specify+a use case *and* a specific revision of that use case.++// terms and definitions+include::terms.adoc[]++## Use Cases+We define these use cases:++* General purpose computing, where the hardware and software of a system+are expected to change over time, and configurations of hardware and software+can be highly variable.+* Appliance computing, where the hardware configuration is essentially+fixed, but software is expected to change.+* Special purpose computing, where hardware and software typically do not+change once shipped from the factory.++### Common Requirements+This section is currently a placeholder.++NOTE: As requirements for individual use cases are uncovered, it is+expected that some will end up being common to all cases.  If so, they+should be moved to this section.++#### Revision History+Common Requirements Current Revision: *0* [September 2020]++### General Purpose Computing+This use case sets out the requirements for what is commonly known+as _general purpose computing_.  For platforms of this type, it is expected+that the user will be able to add or remove cards such as PCIe or SATA, +add or remove devices such as disks, monitors or graphics cards, and will+be able to choose from one or more available operating systems.  Commercial+desktop, laptop or server systems are primary examples.++Operating systems for this use case include at a minimum the members+of the Linux families (Fedora, Debian, Red Hat, SUSE, and similar).  If+a platform is compliant with the requirements of this use case, it should+be possible to easily install and maintain any of the Linux distributions+without modification.++It should also be possible to use any of the other Unix-based operating+systems and distributions such as those in the BSD family, as well as+commercial operating systems such as Microsoft Windows.++The stress here is on the idea of _general_ computing, and hence most of+the readily available operating systems designed for that environment.  The+goal is to be able to seamlessly replace existing systems based on other+ISAs.++#### Revision History+General Purpose Computing Current Revision: *0* [September 2020]++#### RISC-V ISA Requirements+##### Machine Mode+##### Hypervisor Mode+##### Supervisor Mode+. Supervisor-mode environments must implement at least version 20190608+  of the RISC-V Instruction Set Manual Volume II: Privileged+  Specification <<ISAU>>.++. Supervisor-mode environments must implement RV64GC.++. Supervisor-mode environments must implement the Sv39 page-based+  virtual-memory scheme.   Systems that support Sv48 must support+  Sv39, systems that support Sv57 must support Sv48, and so forth.++. Unless otherwise specified by a given I/O device, I/O regions are at+  least point-to-point strongly ordered.  All devices attached to a+  given PCIe root complex are on the same ordered channel (numbered 2+  or above), though different root complexes might not be on the same+  ordering channel.++. On RV64I-based Unix-class systems the negative virtual addresses are+  reserved for the kernel.

I can see the motivation there, though that certainly doesn't come across from the current text. At a minimum it would be good to update this item to clarify if software making negative virtual addresses accessible to U-mode merely risks degrading performance or if it could actually cause correctness/security issues.

ahs3

comment created time in a month

PullRequestReviewEvent

Pull request review commentriscv/riscv-platform-specs

Housekeeping

+# RISC-V Operating System Platform Specification+:author: RISC-V Platform Specification Task Group+:email: tech-unixplatformspec@lists.riscv.org+:revnumber: 0.1.0-draft+:revdate: September 2020+:revremark: Initial version.+:doctype: book+:sectnums:+:toc: macro++// Table of Contents+toc::[]++// Overall document copyrights and licensing+include::licensing.adoc[]++// Document contributors+include::contributors.adoc[]++// Changelog+include::changelog.adoc[]++// Begin the really interesting parts of the document+## Introduction++This document is the RISC-V Operating System Platform Specification+(OSPS).  This specification defines the hardware and firmware+required to be able to install and use one or more operating systems on a+platform built around the RISC-V Instruction Set Architecture (ISA).+The intent is to set out the constraints necessary+for a hardware platform so that an operating system can be assured+it is compatible with that platform, if the platform is in compliance+with this specification.++This specification also sets out the constraints on the+RISCV-V Instruction Set Architecture (ISA) -- at all privilege +levels -- that are needed to provide a consistent and predictable+environment for running these operating systems.++The OSPS sets out the constraints on platforms as _use cases_.  Each+use case specifies a particular combination of hardware platform+and operating system to be used in specific environments.  For example,+the general purpose computing use case specifies the expected hardware+and firmware for systems such as commercial laptop, desktop or server+computers; these use cases generally match acknowledged market+segments possible for RISC-V based platforms.++In order for a platform to be compliant with OSPS, it must be compliant+with a specific use case.  That may allow it to be compliant with other+use cases, but it is recommended that a platform have one specific target+to start from.  For any given use case, all mandatory requirements must be+implemented in the platform.  Optional requirements may or may not be+implemented on any given platform; if such a requirement+could cause the platform to behave differently when not implemented,+a fallback position is specified that must be implemented.++Over time, it is expected that each use case will see a series of+revisions.  Under ideal circumstances, a platform will be compliant+with the most recent version of any use case specification.  When a+platform indicates it is compliant with the OSPS, it should specify+a use case *and* a specific revision of that use case.++// terms and definitions+include::terms.adoc[]++## Use Cases+We define these use cases:++* General purpose computing, where the hardware and software of a system+are expected to change over time, and configurations of hardware and software+can be highly variable.+* Appliance computing, where the hardware configuration is essentially+fixed, but software is expected to change.+* Special purpose computing, where hardware and software typically do not+change once shipped from the factory.++### Common Requirements+This section is currently a placeholder.++NOTE: As requirements for individual use cases are uncovered, it is+expected that some will end up being common to all cases.  If so, they+should be moved to this section.++#### Revision History+Common Requirements Current Revision: *0* [September 2020]++### General Purpose Computing+This use case sets out the requirements for what is commonly known+as _general purpose computing_.  For platforms of this type, it is expected+that the user will be able to add or remove cards such as PCIe or SATA, +add or remove devices such as disks, monitors or graphics cards, and will+be able to choose from one or more available operating systems.  Commercial+desktop, laptop or server systems are primary examples.++Operating systems for this use case include at a minimum the members+of the Linux families (Fedora, Debian, Red Hat, SUSE, and similar).  If+a platform is compliant with the requirements of this use case, it should+be possible to easily install and maintain any of the Linux distributions+without modification.++It should also be possible to use any of the other Unix-based operating+systems and distributions such as those in the BSD family, as well as+commercial operating systems such as Microsoft Windows.++The stress here is on the idea of _general_ computing, and hence most of+the readily available operating systems designed for that environment.  The+goal is to be able to seamlessly replace existing systems based on other+ISAs.++#### Revision History+General Purpose Computing Current Revision: *0* [September 2020]++#### RISC-V ISA Requirements+##### Machine Mode+##### Hypervisor Mode+##### Supervisor Mode+. Supervisor-mode environments must implement at least version 20190608+  of the RISC-V Instruction Set Manual Volume II: Privileged+  Specification <<ISAU>>.++. Supervisor-mode environments must implement RV64GC.

I'm strongly in favor of being opinionated for the "General Purpose Computing" use case if it can simplify things for everyone. If we want to have a separate "Low Cost General Purpose Computing" use case that seems fine, but 64-bit CPUs with floating point have been basically ubiquitous in laptops and servers for many years.

ahs3

comment created time in a month

PullRequestReviewEvent

Pull request review commentriscv/riscv-platform-specs

Housekeeping

+# RISC-V Operating System Platform Specification+:author: RISC-V Platform Specification Task Group+:email: tech-unixplatformspec@lists.riscv.org+:revnumber: 0.1.0-draft+:revdate: September 2020+:revremark: Initial version.+:doctype: book+:sectnums:+:toc: macro++// Table of Contents+toc::[]++// Overall document copyrights and licensing+include::licensing.adoc[]++// Document contributors+include::contributors.adoc[]++// Changelog+include::changelog.adoc[]++// Begin the really interesting parts of the document+## Introduction++This document is the RISC-V Operating System Platform Specification+(OSPS).  This specification defines the hardware and firmware+required to be able to install and use one or more operating systems on a+platform built around the RISC-V Instruction Set Architecture (ISA).+The intent is to set out the constraints necessary+for a hardware platform so that an operating system can be assured+it is compatible with that platform, if the platform is in compliance+with this specification.++This specification also sets out the constraints on the+RISCV-V Instruction Set Architecture (ISA) -- at all privilege +levels -- that are needed to provide a consistent and predictable+environment for running these operating systems.++The OSPS sets out the constraints on platforms as _use cases_.  Each+use case specifies a particular combination of hardware platform+and operating system to be used in specific environments.  For example,+the general purpose computing use case specifies the expected hardware+and firmware for systems such as commercial laptop, desktop or server+computers; these use cases generally match acknowledged market+segments possible for RISC-V based platforms.++In order for a platform to be compliant with OSPS, it must be compliant+with a specific use case.  That may allow it to be compliant with other+use cases, but it is recommended that a platform have one specific target+to start from.  For any given use case, all mandatory requirements must be+implemented in the platform.  Optional requirements may or may not be+implemented on any given platform; if such a requirement+could cause the platform to behave differently when not implemented,+a fallback position is specified that must be implemented.++Over time, it is expected that each use case will see a series of+revisions.  Under ideal circumstances, a platform will be compliant+with the most recent version of any use case specification.  When a+platform indicates it is compliant with the OSPS, it should specify+a use case *and* a specific revision of that use case.++// terms and definitions+include::terms.adoc[]++## Use Cases+We define these use cases:++* General purpose computing, where the hardware and software of a system+are expected to change over time, and configurations of hardware and software+can be highly variable.+* Appliance computing, where the hardware configuration is essentially+fixed, but software is expected to change.+* Special purpose computing, where hardware and software typically do not+change once shipped from the factory.++### Common Requirements+This section is currently a placeholder.++NOTE: As requirements for individual use cases are uncovered, it is+expected that some will end up being common to all cases.  If so, they+should be moved to this section.++#### Revision History+Common Requirements Current Revision: *0* [September 2020]++### General Purpose Computing+This use case sets out the requirements for what is commonly known+as _general purpose computing_.  For platforms of this type, it is expected+that the user will be able to add or remove cards such as PCIe or SATA, +add or remove devices such as disks, monitors or graphics cards, and will+be able to choose from one or more available operating systems.  Commercial+desktop, laptop or server systems are primary examples.++Operating systems for this use case include at a minimum the members+of the Linux families (Fedora, Debian, Red Hat, SUSE, and similar).  If+a platform is compliant with the requirements of this use case, it should+be possible to easily install and maintain any of the Linux distributions+without modification.++It should also be possible to use any of the other Unix-based operating+systems and distributions such as those in the BSD family, as well as+commercial operating systems such as Microsoft Windows.++The stress here is on the idea of _general_ computing, and hence most of+the readily available operating systems designed for that environment.  The+goal is to be able to seamlessly replace existing systems based on other+ISAs.++#### Revision History+General Purpose Computing Current Revision: *0* [September 2020]++#### RISC-V ISA Requirements+##### Machine Mode+##### Hypervisor Mode+##### Supervisor Mode+. Supervisor-mode environments must implement at least version 20190608+  of the RISC-V Instruction Set Manual Volume II: Privileged+  Specification <<ISAU>>.++. Supervisor-mode environments must implement RV64GC.++. Supervisor-mode environments must implement the Sv39 page-based+  virtual-memory scheme.   Systems that support Sv48 must support+  Sv39, systems that support Sv57 must support Sv48, and so forth.++. Unless otherwise specified by a given I/O device, I/O regions are at+  least point-to-point strongly ordered.  All devices attached to a+  given PCIe root complex are on the same ordered channel (numbered 2+  or above), though different root complexes might not be on the same+  ordering channel.++. On RV64I-based Unix-class systems the negative virtual addresses are+  reserved for the kernel.++. External devices (DMA engines, the debug unit, non RISC-V cores, etc.)+  that are visible to RISC-V harts must appear as coherent agents, just+  like any RISC-V hart would.  If additional ordering constraints are+  necessary for a device to function, those will be provided by a+  device-specific mechanism.++##### User Mode+. User-mode environments must implement at least version 20191213+  of the RISC-V Instruction Set Manual Volume I: Unprivileged+  Specification <<ISAP>>.++. User-mode programs may not execute the `fence.i` instruction.++. User-mode environments may provide additional ISA extensions, but if those+  extensions add user-visible state they must be initially disabled.++. Within main-memory regions, aligned instruction fetch must be atomic,+  up to the smaller of ILEN and XLEN bits.  In particular, if an aligned+  4-byte word is stored with the `sw` instruction, then any processor+  attempts to execute that word, the processor either fetches the newly+  stored word, or some previous value stored to that location.  That is,+  the fetched instruction is not an unpredictable value, nor is it a+  hybrid of the bytes of the old and new values.++. LR/SC forward progress is guaranteed on main memory regions that are+  cacheable and coherent.++#### Memory Requirements+##### Physical Memory+###### Misaligned Physical-Memory Access Atomicity++Consider a data memory access of size _w_ to physical address _p0_,+where _w_ does not evenly divide _p0_.  Let _p1_ denote+the physical address of the last byte of the access, and let *P* denote the+address pair *(* _p0_, _p1_ *)*.  There are two cases:++. *P* lies within a single physical-memory region.  One of the following+   holds:++   .. Loads and stores to *P* execute atomically with respect to other+      accesses to *P*.  AMOs to *P* either execute atomically+      with respect to other accesses to *P* or raise access+      exceptions.  LRs and SCs to *P* either execute atomically+      with respect to other accesses to *P* or raise access exceptions.++   .. Loads and stores to *P* execute without guarantee of atomicity.  AMOs,+      LRs, and SCs to *P* raise access exceptions.++. *P* spans two physical-memory regions. AMOs, LRs, and SCs all raise access+   exceptions.  Additionally, one of the following holds:++   .. Loads and stores to *P* raise access exceptions.++   .. Loads and stores to *P* succeed without guarantee of atomicity.++   .. Loads and stores to *P* proceed partially, then raise access exceptions.+      No register writebacks occur.++##### Addressable Memory++##### Virtual Memory+###### Misaligned Virtual-Memory Access Atomicity+Consider a data memory access of size _w_ to virtual address _v0_,+where _w_ does not evenly divide _v0_.  Let _v1_ denote+the virtual address of the last byte of the access.  Let _p0_ and+_p1_ be the physical addresses corresponding to _v0_ and+_v1_, if translations exist.  One of the following must hold:++. _v0_ is an impermissible virtual address; the access raises+  a page-fault exception with trap value _v0_.++. _v0_ is a permissible virtual address; _v1_ lies in a different,+  impermissible page.  The access raises a page-fault exception with+  a trap value equal to the base virtual address of the page +  containing _v1_.  Alternatively, if the same access to physical-address+  pair *(* _p0_, _p0_ + _w_ - 1 *)* would have caused an access exception,+  the implementation may raise that exception instead.  This design+  simplifies the emulation of misaligned accesses in more-privileged+  software.++. _v0_ and _v1_ are both permissible virtual addresses.  The access+  proceeds according to the misaligned physical-memory access rules+  above, noting that _v0_ and _v1_ may lie in different physical memory+  regions, despite their virtual contiguity.++##### Memory Maps++#### Required Hardware Components+##### Interrupt Controller+##### MMU+##### DMA+##### Memory-mapped I/O+##### IOMMU (for virtualization)+##### Power Management+##### CPU Frequency Control+##### Thermal Management++#### Firmware Requirements+##### SMBIOS/DMI+##### IPMI+##### UEFI+##### ACPI+##### Updating Firmware++#### Boot Sequence Requirements++#### Boot Protocol Requirements+++### Appliance Computing+This use case sets out the requirements for _appliance computing_.+For platforms of this type, it is expected that the user will *NOT*+be able to add or remove cards or devices, with the possible exception+of adding memory devices such as SD cards.  The hardware in such a+system is essentially fixed for the life of the device.  Primary+examples are devices such as tablets, smart phones, automobile systems,+or even some refrigerators.++The operating system and applications on such appliances may change+over time.  However, the owner of the device will not be able to+arbitrarily change the operating system or firmware installed (unless+they are _really_ clever); in general, this would be fairly strictly+controlled by the device manufacturer.++Operating systems for this use case could include members of the Linux+families (Fedora, Debian, Red Hat, SUSE, and similar).  When a platform+is compliant with the requirements of this use case, it should be+possible to install and maintain the Linux distributions, but modification+or specialization of the OS or firmware may be required.++It should also be possible to use any of the other Unix-based operating+systems and distributions such as those in the BSD family, as well as+commercial operating systems such as Microsoft Windows.  Again, some+modification or specialization may be required.++Real-Time Operating Systems (RTOSs) will play a role here as well,+depending on how the platform is being used.  Whether or not there+is a standard amenable to all RTOSs is TBD.

Perhaps the general computing section should be written first targeting servers, desktops, and laptops? With that written it might be clear whether it would also work for phones/tablets (yay less work!) or perhaps there will be requirements that don't make sense for them (in which case a "appliance computing" use case is needed)

ahs3

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentriscv/riscv-platform-specs

Housekeeping

+# RISC-V Operating System Platform Specification+:author: RISC-V Platform Specification Task Group+:email: tech-unixplatformspec@lists.riscv.org+:revnumber: 0.1.0-draft+:revdate: September 2020+:revremark: Initial version.+:doctype: book+:sectnums:+:toc: macro++// Table of Contents+toc::[]++// Overall document copyrights and licensing+include::licensing.adoc[]++// Document contributors+include::contributors.adoc[]++// Changelog+include::changelog.adoc[]++// Begin the really interesting parts of the document+## Introduction++This document is the RISC-V Operating System Platform Specification+(OSPS).  This specification defines the hardware and firmware+required to be able to install and use one or more operating systems on a+platform built around the RISC-V Instruction Set Architecture (ISA).+The intent is to set out the constraints necessary+for a hardware platform so that an operating system can be assured+it is compatible with that platform, if the platform is in compliance+with this specification.++This specification also sets out the constraints on the+RISCV-V Instruction Set Architecture (ISA) -- at all privilege +levels -- that are needed to provide a consistent and predictable+environment for running these operating systems.++The OSPS sets out the constraints on platforms as _use cases_.  Each+use case specifies a particular combination of hardware platform+and operating system to be used in specific environments.  For example,+the general purpose computing use case specifies the expected hardware+and firmware for systems such as commercial laptop, desktop or server+computers; these use cases generally match acknowledged market+segments possible for RISC-V based platforms.++In order for a platform to be compliant with OSPS, it must be compliant+with a specific use case.  That may allow it to be compliant with other+use cases, but it is recommended that a platform have one specific target+to start from.  For any given use case, all mandatory requirements must be+implemented in the platform.  Optional requirements may or may not be+implemented on any given platform; if such a requirement+could cause the platform to behave differently when not implemented,+a fallback position is specified that must be implemented.++Over time, it is expected that each use case will see a series of+revisions.  Under ideal circumstances, a platform will be compliant+with the most recent version of any use case specification.  When a+platform indicates it is compliant with the OSPS, it should specify+a use case *and* a specific revision of that use case.++// terms and definitions+include::terms.adoc[]++## Use Cases+We define these use cases:++* General purpose computing, where the hardware and software of a system+are expected to change over time, and configurations of hardware and software+can be highly variable.+* Appliance computing, where the hardware configuration is essentially+fixed, but software is expected to change.+* Special purpose computing, where hardware and software typically do not+change once shipped from the factory.++### Common Requirements+This section is currently a placeholder.++NOTE: As requirements for individual use cases are uncovered, it is+expected that some will end up being common to all cases.  If so, they+should be moved to this section.++#### Revision History+Common Requirements Current Revision: *0* [September 2020]++### General Purpose Computing+This use case sets out the requirements for what is commonly known+as _general purpose computing_.  For platforms of this type, it is expected+that the user will be able to add or remove cards such as PCIe or SATA, +add or remove devices such as disks, monitors or graphics cards, and will+be able to choose from one or more available operating systems.  Commercial+desktop, laptop or server systems are primary examples.++Operating systems for this use case include at a minimum the members+of the Linux families (Fedora, Debian, Red Hat, SUSE, and similar).  If+a platform is compliant with the requirements of this use case, it should+be possible to easily install and maintain any of the Linux distributions+without modification.++It should also be possible to use any of the other Unix-based operating+systems and distributions such as those in the BSD family, as well as+commercial operating systems such as Microsoft Windows.++The stress here is on the idea of _general_ computing, and hence most of+the readily available operating systems designed for that environment.  The+goal is to be able to seamlessly replace existing systems based on other+ISAs.++#### Revision History+General Purpose Computing Current Revision: *0* [September 2020]++#### RISC-V ISA Requirements+##### Machine Mode+##### Hypervisor Mode+##### Supervisor Mode+. Supervisor-mode environments must implement at least version 20190608+  of the RISC-V Instruction Set Manual Volume II: Privileged+  Specification <<ISAU>>.++. Supervisor-mode environments must implement RV64GC.++. Supervisor-mode environments must implement the Sv39 page-based+  virtual-memory scheme.   Systems that support Sv48 must support+  Sv39, systems that support Sv57 must support Sv48, and so forth.++. Unless otherwise specified by a given I/O device, I/O regions are at+  least point-to-point strongly ordered.  All devices attached to a+  given PCIe root complex are on the same ordered channel (numbered 2+  or above), though different root complexes might not be on the same+  ordering channel.++. On RV64I-based Unix-class systems the negative virtual addresses are+  reserved for the kernel.++. External devices (DMA engines, the debug unit, non RISC-V cores, etc.)+  that are visible to RISC-V harts must appear as coherent agents, just+  like any RISC-V hart would.  If additional ordering constraints are+  necessary for a device to function, those will be provided by a+  device-specific mechanism.++##### User Mode+. User-mode environments must implement at least version 20191213+  of the RISC-V Instruction Set Manual Volume I: Unprivileged+  Specification <<ISAP>>.++. User-mode programs may not execute the `fence.i` instruction.++. User-mode environments may provide additional ISA extensions, but if those+  extensions add user-visible state they must be initially disabled.++. Within main-memory regions, aligned instruction fetch must be atomic,+  up to the smaller of ILEN and XLEN bits.  In particular, if an aligned+  4-byte word is stored with the `sw` instruction, then any processor+  attempts to execute that word, the processor either fetches the newly+  stored word, or some previous value stored to that location.  That is,+  the fetched instruction is not an unpredictable value, nor is it a+  hybrid of the bytes of the old and new values.++. LR/SC forward progress is guaranteed on main memory regions that are+  cacheable and coherent.++#### Memory Requirements+##### Physical Memory+###### Misaligned Physical-Memory Access Atomicity++Consider a data memory access of size _w_ to physical address _p0_,+where _w_ does not evenly divide _p0_.  Let _p1_ denote+the physical address of the last byte of the access, and let *P* denote the+address pair *(* _p0_, _p1_ *)*.  There are two cases:++. *P* lies within a single physical-memory region.  One of the following+   holds:++   .. Loads and stores to *P* execute atomically with respect to other+      accesses to *P*.  AMOs to *P* either execute atomically+      with respect to other accesses to *P* or raise access+      exceptions.  LRs and SCs to *P* either execute atomically+      with respect to other accesses to *P* or raise access exceptions.++   .. Loads and stores to *P* execute without guarantee of atomicity.  AMOs,+      LRs, and SCs to *P* raise access exceptions.++. *P* spans two physical-memory regions. AMOs, LRs, and SCs all raise access+   exceptions.  Additionally, one of the following holds:++   .. Loads and stores to *P* raise access exceptions.++   .. Loads and stores to *P* succeed without guarantee of atomicity.++   .. Loads and stores to *P* proceed partially, then raise access exceptions.+      No register writebacks occur.++##### Addressable Memory++##### Virtual Memory+###### Misaligned Virtual-Memory Access Atomicity+Consider a data memory access of size _w_ to virtual address _v0_,+where _w_ does not evenly divide _v0_.  Let _v1_ denote+the virtual address of the last byte of the access.  Let _p0_ and+_p1_ be the physical addresses corresponding to _v0_ and+_v1_, if translations exist.  One of the following must hold:++. _v0_ is an impermissible virtual address; the access raises+  a page-fault exception with trap value _v0_.++. _v0_ is a permissible virtual address; _v1_ lies in a different,+  impermissible page.  The access raises a page-fault exception with+  a trap value equal to the base virtual address of the page +  containing _v1_.  Alternatively, if the same access to physical-address+  pair *(* _p0_, _p0_ + _w_ - 1 *)* would have caused an access exception,+  the implementation may raise that exception instead.  This design+  simplifies the emulation of misaligned accesses in more-privileged+  software.++. _v0_ and _v1_ are both permissible virtual addresses.  The access+  proceeds according to the misaligned physical-memory access rules+  above, noting that _v0_ and _v1_ may lie in different physical memory+  regions, despite their virtual contiguity.++##### Memory Maps++#### Required Hardware Components+##### Interrupt Controller+##### MMU+##### DMA+##### Memory-mapped I/O+##### IOMMU (for virtualization)+##### Power Management+##### CPU Frequency Control+##### Thermal Management++#### Firmware Requirements+##### SMBIOS/DMI+##### IPMI+##### UEFI+##### ACPI+##### Updating Firmware++#### Boot Sequence Requirements++#### Boot Protocol Requirements+++### Appliance Computing+This use case sets out the requirements for _appliance computing_.+For platforms of this type, it is expected that the user will *NOT*+be able to add or remove cards or devices, with the possible exception+of adding memory devices such as SD cards.  The hardware in such a+system is essentially fixed for the life of the device.  Primary+examples are devices such as tablets, smart phones, automobile systems,+or even some refrigerators.++The operating system and applications on such appliances may change+over time.  However, the owner of the device will not be able to+arbitrarily change the operating system or firmware installed (unless+they are _really_ clever); in general, this would be fairly strictly+controlled by the device manufacturer.++Operating systems for this use case could include members of the Linux+families (Fedora, Debian, Red Hat, SUSE, and similar).  When a platform+is compliant with the requirements of this use case, it should be+possible to install and maintain the Linux distributions, but modification+or specialization of the OS or firmware may be required.++It should also be possible to use any of the other Unix-based operating+systems and distributions such as those in the BSD family, as well as+commercial operating systems such as Microsoft Windows.  Again, some+modification or specialization may be required.++Real-Time Operating Systems (RTOSs) will play a role here as well,+depending on how the platform is being used.  Whether or not there+is a standard amenable to all RTOSs is TBD.++The stress here is on the idea of _appliances_ -- devices meant to+meet a specific need, with flexible levels of functionality, but+running on a consistent and unchanging set of hardware.+

To me, those boards would fall into the very low end of the general computing category. For instance, the marketing on the Raspberry Pi 4 starts with "Your tiny, dual-display, desktop computer..."

ahs3

comment created time in a month

PullRequestReviewEvent

Pull request review commentriscv/riscv-platform-specs

Housekeeping

+# RISC-V Operating System Platform Specification+:author: RISC-V Platform Specification Task Group+:email: tech-unixplatformspec@lists.riscv.org+:revnumber: 0.1.0-draft+:revdate: September 2020+:revremark: Initial version.+:doctype: book+:sectnums:+:toc: macro++// Table of Contents+toc::[]++// Overall document copyrights and licensing+include::licensing.adoc[]++// Document contributors+include::contributors.adoc[]++// Changelog+include::changelog.adoc[]++// Begin the really interesting parts of the document+## Introduction++This document is the RISC-V Operating System Platform Specification+(OSPS).  This specification defines the hardware and firmware+required to be able to install and use one or more operating systems on a+platform built around the RISC-V Instruction Set Architecture (ISA).+The intent is to set out the constraints necessary+for a hardware platform so that an operating system can be assured+it is compatible with that platform, if the platform is in compliance+with this specification.++This specification also sets out the constraints on the+RISCV-V Instruction Set Architecture (ISA) -- at all privilege +levels -- that are needed to provide a consistent and predictable+environment for running these operating systems.++The OSPS sets out the constraints on platforms as _use cases_.  Each+use case specifies a particular combination of hardware platform+and operating system to be used in specific environments.  For example,+the general purpose computing use case specifies the expected hardware+and firmware for systems such as commercial laptop, desktop or server+computers; these use cases generally match acknowledged market+segments possible for RISC-V based platforms.++In order for a platform to be compliant with OSPS, it must be compliant+with a specific use case.  That may allow it to be compliant with other+use cases, but it is recommended that a platform have one specific target+to start from.  For any given use case, all mandatory requirements must be+implemented in the platform.  Optional requirements may or may not be+implemented on any given platform; if such a requirement+could cause the platform to behave differently when not implemented,+a fallback position is specified that must be implemented.++Over time, it is expected that each use case will see a series of+revisions.  Under ideal circumstances, a platform will be compliant+with the most recent version of any use case specification.  When a+platform indicates it is compliant with the OSPS, it should specify+a use case *and* a specific revision of that use case.++// terms and definitions+include::terms.adoc[]++## Use Cases+We define these use cases:++* General purpose computing, where the hardware and software of a system+are expected to change over time, and configurations of hardware and software+can be highly variable.+* Appliance computing, where the hardware configuration is essentially+fixed, but software is expected to change.+* Special purpose computing, where hardware and software typically do not+change once shipped from the factory.++### Common Requirements+This section is currently a placeholder.++NOTE: As requirements for individual use cases are uncovered, it is+expected that some will end up being common to all cases.  If so, they+should be moved to this section.++#### Revision History+Common Requirements Current Revision: *0* [September 2020]++### General Purpose Computing+This use case sets out the requirements for what is commonly known+as _general purpose computing_.  For platforms of this type, it is expected+that the user will be able to add or remove cards such as PCIe or SATA, +add or remove devices such as disks, monitors or graphics cards, and will+be able to choose from one or more available operating systems.  Commercial+desktop, laptop or server systems are primary examples.++Operating systems for this use case include at a minimum the members+of the Linux families (Fedora, Debian, Red Hat, SUSE, and similar).  If+a platform is compliant with the requirements of this use case, it should+be possible to easily install and maintain any of the Linux distributions+without modification.++It should also be possible to use any of the other Unix-based operating+systems and distributions such as those in the BSD family, as well as+commercial operating systems such as Microsoft Windows.++The stress here is on the idea of _general_ computing, and hence most of+the readily available operating systems designed for that environment.  The+goal is to be able to seamlessly replace existing systems based on other+ISAs.++#### Revision History+General Purpose Computing Current Revision: *0* [September 2020]++#### RISC-V ISA Requirements+##### Machine Mode+##### Hypervisor Mode+##### Supervisor Mode+. Supervisor-mode environments must implement at least version 20190608+  of the RISC-V Instruction Set Manual Volume II: Privileged+  Specification <<ISAU>>.++. Supervisor-mode environments must implement RV64GC.++. Supervisor-mode environments must implement the Sv39 page-based+  virtual-memory scheme.   Systems that support Sv48 must support+  Sv39, systems that support Sv57 must support Sv48, and so forth.++. Unless otherwise specified by a given I/O device, I/O regions are at+  least point-to-point strongly ordered.  All devices attached to a+  given PCIe root complex are on the same ordered channel (numbered 2+  or above), though different root complexes might not be on the same+  ordering channel.++. On RV64I-based Unix-class systems the negative virtual addresses are+  reserved for the kernel.

I'm not sure this belongs in the "ISA requirements" section? If anything this is a requirement on user software not to try to use kernel addresses.

ahs3

comment created time in a month

Pull request review commentriscv/riscv-platform-specs

Housekeeping

+# RISC-V Operating System Platform Specification+:author: RISC-V Platform Specification Task Group+:email: tech-unixplatformspec@lists.riscv.org+:revnumber: 0.1.0-draft+:revdate: September 2020+:revremark: Initial version.+:doctype: book+:sectnums:+:toc: macro++// Table of Contents+toc::[]++// Overall document copyrights and licensing+include::licensing.adoc[]++// Document contributors+include::contributors.adoc[]++// Changelog+include::changelog.adoc[]++// Begin the really interesting parts of the document+## Introduction++This document is the RISC-V Operating System Platform Specification+(OSPS).  This specification defines the hardware and firmware+required to be able to install and use one or more operating systems on a+platform built around the RISC-V Instruction Set Architecture (ISA).+The intent is to set out the constraints necessary+for a hardware platform so that an operating system can be assured+it is compatible with that platform, if the platform is in compliance+with this specification.++This specification also sets out the constraints on the+RISCV-V Instruction Set Architecture (ISA) -- at all privilege +levels -- that are needed to provide a consistent and predictable+environment for running these operating systems.++The OSPS sets out the constraints on platforms as _use cases_.  Each+use case specifies a particular combination of hardware platform+and operating system to be used in specific environments.  For example,+the general purpose computing use case specifies the expected hardware+and firmware for systems such as commercial laptop, desktop or server+computers; these use cases generally match acknowledged market+segments possible for RISC-V based platforms.++In order for a platform to be compliant with OSPS, it must be compliant+with a specific use case.  That may allow it to be compliant with other+use cases, but it is recommended that a platform have one specific target+to start from.  For any given use case, all mandatory requirements must be+implemented in the platform.  Optional requirements may or may not be+implemented on any given platform; if such a requirement+could cause the platform to behave differently when not implemented,+a fallback position is specified that must be implemented.++Over time, it is expected that each use case will see a series of+revisions.  Under ideal circumstances, a platform will be compliant+with the most recent version of any use case specification.  When a+platform indicates it is compliant with the OSPS, it should specify+a use case *and* a specific revision of that use case.++// terms and definitions+include::terms.adoc[]++## Use Cases+We define these use cases:++* General purpose computing, where the hardware and software of a system+are expected to change over time, and configurations of hardware and software+can be highly variable.+* Appliance computing, where the hardware configuration is essentially+fixed, but software is expected to change.+* Special purpose computing, where hardware and software typically do not+change once shipped from the factory.++### Common Requirements+This section is currently a placeholder.++NOTE: As requirements for individual use cases are uncovered, it is+expected that some will end up being common to all cases.  If so, they+should be moved to this section.++#### Revision History+Common Requirements Current Revision: *0* [September 2020]++### General Purpose Computing+This use case sets out the requirements for what is commonly known+as _general purpose computing_.  For platforms of this type, it is expected+that the user will be able to add or remove cards such as PCIe or SATA, +add or remove devices such as disks, monitors or graphics cards, and will+be able to choose from one or more available operating systems.  Commercial+desktop, laptop or server systems are primary examples.++Operating systems for this use case include at a minimum the members+of the Linux families (Fedora, Debian, Red Hat, SUSE, and similar).  If+a platform is compliant with the requirements of this use case, it should+be possible to easily install and maintain any of the Linux distributions+without modification.++It should also be possible to use any of the other Unix-based operating+systems and distributions such as those in the BSD family, as well as+commercial operating systems such as Microsoft Windows.++The stress here is on the idea of _general_ computing, and hence most of+the readily available operating systems designed for that environment.  The+goal is to be able to seamlessly replace existing systems based on other+ISAs.++#### Revision History+General Purpose Computing Current Revision: *0* [September 2020]++#### RISC-V ISA Requirements+##### Machine Mode+##### Hypervisor Mode+##### Supervisor Mode+. Supervisor-mode environments must implement at least version 20190608+  of the RISC-V Instruction Set Manual Volume II: Privileged+  Specification <<ISAU>>.++. Supervisor-mode environments must implement RV64GC.++. Supervisor-mode environments must implement the Sv39 page-based+  virtual-memory scheme.   Systems that support Sv48 must support+  Sv39, systems that support Sv57 must support Sv48, and so forth.++. Unless otherwise specified by a given I/O device, I/O regions are at+  least point-to-point strongly ordered.  All devices attached to a+  given PCIe root complex are on the same ordered channel (numbered 2+  or above), though different root complexes might not be on the same+  ordering channel.++. On RV64I-based Unix-class systems the negative virtual addresses are+  reserved for the kernel.++. External devices (DMA engines, the debug unit, non RISC-V cores, etc.)+  that are visible to RISC-V harts must appear as coherent agents, just+  like any RISC-V hart would.  If additional ordering constraints are+  necessary for a device to function, those will be provided by a+  device-specific mechanism.++##### User Mode+. User-mode environments must implement at least version 20191213+  of the RISC-V Instruction Set Manual Volume I: Unprivileged+  Specification <<ISAP>>.++. User-mode programs may not execute the `fence.i` instruction.++. User-mode environments may provide additional ISA extensions, but if those+  extensions add user-visible state they must be initially disabled.++. Within main-memory regions, aligned instruction fetch must be atomic,+  up to the smaller of ILEN and XLEN bits.  In particular, if an aligned

Don't we require that XLEN=64 bits?

ahs3

comment created time in a month

Pull request review commentriscv/riscv-platform-specs

Housekeeping

+# RISC-V Operating System Platform Specification+:author: RISC-V Platform Specification Task Group+:email: tech-unixplatformspec@lists.riscv.org+:revnumber: 0.1.0-draft+:revdate: September 2020+:revremark: Initial version.+:doctype: book+:sectnums:+:toc: macro++// Table of Contents+toc::[]++// Overall document copyrights and licensing+include::licensing.adoc[]++// Document contributors+include::contributors.adoc[]++// Changelog+include::changelog.adoc[]++// Begin the really interesting parts of the document+## Introduction++This document is the RISC-V Operating System Platform Specification+(OSPS).  This specification defines the hardware and firmware+required to be able to install and use one or more operating systems on a+platform built around the RISC-V Instruction Set Architecture (ISA).+The intent is to set out the constraints necessary+for a hardware platform so that an operating system can be assured+it is compatible with that platform, if the platform is in compliance+with this specification.++This specification also sets out the constraints on the+RISCV-V Instruction Set Architecture (ISA) -- at all privilege +levels -- that are needed to provide a consistent and predictable+environment for running these operating systems.++The OSPS sets out the constraints on platforms as _use cases_.  Each+use case specifies a particular combination of hardware platform+and operating system to be used in specific environments.  For example,+the general purpose computing use case specifies the expected hardware+and firmware for systems such as commercial laptop, desktop or server+computers; these use cases generally match acknowledged market+segments possible for RISC-V based platforms.++In order for a platform to be compliant with OSPS, it must be compliant+with a specific use case.  That may allow it to be compliant with other+use cases, but it is recommended that a platform have one specific target+to start from.  For any given use case, all mandatory requirements must be+implemented in the platform.  Optional requirements may or may not be+implemented on any given platform; if such a requirement+could cause the platform to behave differently when not implemented,+a fallback position is specified that must be implemented.++Over time, it is expected that each use case will see a series of+revisions.  Under ideal circumstances, a platform will be compliant+with the most recent version of any use case specification.  When a+platform indicates it is compliant with the OSPS, it should specify+a use case *and* a specific revision of that use case.++// terms and definitions+include::terms.adoc[]++## Use Cases+We define these use cases:++* General purpose computing, where the hardware and software of a system+are expected to change over time, and configurations of hardware and software+can be highly variable.+* Appliance computing, where the hardware configuration is essentially+fixed, but software is expected to change.+* Special purpose computing, where hardware and software typically do not+change once shipped from the factory.++### Common Requirements+This section is currently a placeholder.++NOTE: As requirements for individual use cases are uncovered, it is+expected that some will end up being common to all cases.  If so, they+should be moved to this section.++#### Revision History+Common Requirements Current Revision: *0* [September 2020]++### General Purpose Computing+This use case sets out the requirements for what is commonly known+as _general purpose computing_.  For platforms of this type, it is expected+that the user will be able to add or remove cards such as PCIe or SATA, +add or remove devices such as disks, monitors or graphics cards, and will+be able to choose from one or more available operating systems.  Commercial+desktop, laptop or server systems are primary examples.++Operating systems for this use case include at a minimum the members+of the Linux families (Fedora, Debian, Red Hat, SUSE, and similar).  If+a platform is compliant with the requirements of this use case, it should+be possible to easily install and maintain any of the Linux distributions+without modification.++It should also be possible to use any of the other Unix-based operating+systems and distributions such as those in the BSD family, as well as+commercial operating systems such as Microsoft Windows.++The stress here is on the idea of _general_ computing, and hence most of+the readily available operating systems designed for that environment.  The+goal is to be able to seamlessly replace existing systems based on other+ISAs.++#### Revision History+General Purpose Computing Current Revision: *0* [September 2020]++#### RISC-V ISA Requirements+##### Machine Mode+##### Hypervisor Mode+##### Supervisor Mode+. Supervisor-mode environments must implement at least version 20190608+  of the RISC-V Instruction Set Manual Volume II: Privileged+  Specification <<ISAU>>.++. Supervisor-mode environments must implement RV64GC.++. Supervisor-mode environments must implement the Sv39 page-based+  virtual-memory scheme.   Systems that support Sv48 must support+  Sv39, systems that support Sv57 must support Sv48, and so forth.++. Unless otherwise specified by a given I/O device, I/O regions are at+  least point-to-point strongly ordered.  All devices attached to a+  given PCIe root complex are on the same ordered channel (numbered 2+  or above), though different root complexes might not be on the same+  ordering channel.++. On RV64I-based Unix-class systems the negative virtual addresses are+  reserved for the kernel.++. External devices (DMA engines, the debug unit, non RISC-V cores, etc.)+  that are visible to RISC-V harts must appear as coherent agents, just+  like any RISC-V hart would.  If additional ordering constraints are+  necessary for a device to function, those will be provided by a+  device-specific mechanism.++##### User Mode+. User-mode environments must implement at least version 20191213+  of the RISC-V Instruction Set Manual Volume I: Unprivileged+  Specification <<ISAP>>.++. User-mode programs may not execute the `fence.i` instruction.

This seems to imply that untrusted user-mode programs can't be executed, since otherwise how could you enforce this requirement?

ahs3

comment created time in a month

Pull request review commentriscv/riscv-platform-specs

Housekeeping

+# RISC-V Operating System Platform Specification+:author: RISC-V Platform Specification Task Group+:email: tech-unixplatformspec@lists.riscv.org+:revnumber: 0.1.0-draft+:revdate: September 2020+:revremark: Initial version.+:doctype: book+:sectnums:+:toc: macro++// Table of Contents+toc::[]++// Overall document copyrights and licensing+include::licensing.adoc[]++// Document contributors+include::contributors.adoc[]++// Changelog+include::changelog.adoc[]++// Begin the really interesting parts of the document+## Introduction++This document is the RISC-V Operating System Platform Specification+(OSPS).  This specification defines the hardware and firmware+required to be able to install and use one or more operating systems on a+platform built around the RISC-V Instruction Set Architecture (ISA).+The intent is to set out the constraints necessary+for a hardware platform so that an operating system can be assured+it is compatible with that platform, if the platform is in compliance+with this specification.++This specification also sets out the constraints on the+RISCV-V Instruction Set Architecture (ISA) -- at all privilege +levels -- that are needed to provide a consistent and predictable+environment for running these operating systems.++The OSPS sets out the constraints on platforms as _use cases_.  Each+use case specifies a particular combination of hardware platform+and operating system to be used in specific environments.  For example,+the general purpose computing use case specifies the expected hardware+and firmware for systems such as commercial laptop, desktop or server+computers; these use cases generally match acknowledged market+segments possible for RISC-V based platforms.++In order for a platform to be compliant with OSPS, it must be compliant+with a specific use case.  That may allow it to be compliant with other+use cases, but it is recommended that a platform have one specific target+to start from.  For any given use case, all mandatory requirements must be+implemented in the platform.  Optional requirements may or may not be+implemented on any given platform; if such a requirement+could cause the platform to behave differently when not implemented,+a fallback position is specified that must be implemented.++Over time, it is expected that each use case will see a series of+revisions.  Under ideal circumstances, a platform will be compliant+with the most recent version of any use case specification.  When a+platform indicates it is compliant with the OSPS, it should specify+a use case *and* a specific revision of that use case.++// terms and definitions+include::terms.adoc[]++## Use Cases+We define these use cases:++* General purpose computing, where the hardware and software of a system+are expected to change over time, and configurations of hardware and software+can be highly variable.+* Appliance computing, where the hardware configuration is essentially+fixed, but software is expected to change.+* Special purpose computing, where hardware and software typically do not+change once shipped from the factory.++### Common Requirements+This section is currently a placeholder.++NOTE: As requirements for individual use cases are uncovered, it is+expected that some will end up being common to all cases.  If so, they+should be moved to this section.++#### Revision History+Common Requirements Current Revision: *0* [September 2020]++### General Purpose Computing+This use case sets out the requirements for what is commonly known+as _general purpose computing_.  For platforms of this type, it is expected+that the user will be able to add or remove cards such as PCIe or SATA, +add or remove devices such as disks, monitors or graphics cards, and will+be able to choose from one or more available operating systems.  Commercial+desktop, laptop or server systems are primary examples.++Operating systems for this use case include at a minimum the members+of the Linux families (Fedora, Debian, Red Hat, SUSE, and similar).  If+a platform is compliant with the requirements of this use case, it should+be possible to easily install and maintain any of the Linux distributions+without modification.++It should also be possible to use any of the other Unix-based operating+systems and distributions such as those in the BSD family, as well as+commercial operating systems such as Microsoft Windows.++The stress here is on the idea of _general_ computing, and hence most of+the readily available operating systems designed for that environment.  The+goal is to be able to seamlessly replace existing systems based on other+ISAs.++#### Revision History+General Purpose Computing Current Revision: *0* [September 2020]++#### RISC-V ISA Requirements+##### Machine Mode+##### Hypervisor Mode+##### Supervisor Mode+. Supervisor-mode environments must implement at least version 20190608+  of the RISC-V Instruction Set Manual Volume II: Privileged+  Specification <<ISAU>>.++. Supervisor-mode environments must implement RV64GC.++. Supervisor-mode environments must implement the Sv39 page-based+  virtual-memory scheme.   Systems that support Sv48 must support+  Sv39, systems that support Sv57 must support Sv48, and so forth.++. Unless otherwise specified by a given I/O device, I/O regions are at+  least point-to-point strongly ordered.  All devices attached to a+  given PCIe root complex are on the same ordered channel (numbered 2+  or above), though different root complexes might not be on the same+  ordering channel.++. On RV64I-based Unix-class systems the negative virtual addresses are+  reserved for the kernel.++. External devices (DMA engines, the debug unit, non RISC-V cores, etc.)+  that are visible to RISC-V harts must appear as coherent agents, just+  like any RISC-V hart would.  If additional ordering constraints are+  necessary for a device to function, those will be provided by a+  device-specific mechanism.++##### User Mode+. User-mode environments must implement at least version 20191213+  of the RISC-V Instruction Set Manual Volume I: Unprivileged+  Specification <<ISAP>>.++. User-mode programs may not execute the `fence.i` instruction.++. User-mode environments may provide additional ISA extensions, but if those+  extensions add user-visible state they must be initially disabled.++. Within main-memory regions, aligned instruction fetch must be atomic,+  up to the smaller of ILEN and XLEN bits.  In particular, if an aligned+  4-byte word is stored with the `sw` instruction, then any processor+  attempts to execute that word, the processor either fetches the newly+  stored word, or some previous value stored to that location.  That is,+  the fetched instruction is not an unpredictable value, nor is it a+  hybrid of the bytes of the old and new values.++. LR/SC forward progress is guaranteed on main memory regions that are+  cacheable and coherent.++#### Memory Requirements+##### Physical Memory+###### Misaligned Physical-Memory Access Atomicity++Consider a data memory access of size _w_ to physical address _p0_,+where _w_ does not evenly divide _p0_.  Let _p1_ denote+the physical address of the last byte of the access, and let *P* denote the+address pair *(* _p0_, _p1_ *)*.  There are two cases:++. *P* lies within a single physical-memory region.  One of the following+   holds:++   .. Loads and stores to *P* execute atomically with respect to other+      accesses to *P*.  AMOs to *P* either execute atomically+      with respect to other accesses to *P* or raise access+      exceptions.  LRs and SCs to *P* either execute atomically+      with respect to other accesses to *P* or raise access exceptions.++   .. Loads and stores to *P* execute without guarantee of atomicity.  AMOs,+      LRs, and SCs to *P* raise access exceptions.++. *P* spans two physical-memory regions. AMOs, LRs, and SCs all raise access+   exceptions.  Additionally, one of the following holds:++   .. Loads and stores to *P* raise access exceptions.++   .. Loads and stores to *P* succeed without guarantee of atomicity.++   .. Loads and stores to *P* proceed partially, then raise access exceptions.+      No register writebacks occur.++##### Addressable Memory++##### Virtual Memory+###### Misaligned Virtual-Memory Access Atomicity+Consider a data memory access of size _w_ to virtual address _v0_,+where _w_ does not evenly divide _v0_.  Let _v1_ denote+the virtual address of the last byte of the access.  Let _p0_ and+_p1_ be the physical addresses corresponding to _v0_ and+_v1_, if translations exist.  One of the following must hold:++. _v0_ is an impermissible virtual address; the access raises+  a page-fault exception with trap value _v0_.++. _v0_ is a permissible virtual address; _v1_ lies in a different,+  impermissible page.  The access raises a page-fault exception with+  a trap value equal to the base virtual address of the page +  containing _v1_.  Alternatively, if the same access to physical-address+  pair *(* _p0_, _p0_ + _w_ - 1 *)* would have caused an access exception,+  the implementation may raise that exception instead.  This design+  simplifies the emulation of misaligned accesses in more-privileged+  software.++. _v0_ and _v1_ are both permissible virtual addresses.  The access+  proceeds according to the misaligned physical-memory access rules+  above, noting that _v0_ and _v1_ may lie in different physical memory+  regions, despite their virtual contiguity.++##### Memory Maps++#### Required Hardware Components+##### Interrupt Controller+##### MMU+##### DMA+##### Memory-mapped I/O+##### IOMMU (for virtualization)+##### Power Management+##### CPU Frequency Control+##### Thermal Management++#### Firmware Requirements+##### SMBIOS/DMI+##### IPMI+##### UEFI+##### ACPI+##### Updating Firmware++#### Boot Sequence Requirements++#### Boot Protocol Requirements+++### Appliance Computing+This use case sets out the requirements for _appliance computing_.+For platforms of this type, it is expected that the user will *NOT*+be able to add or remove cards or devices, with the possible exception+of adding memory devices such as SD cards.  The hardware in such a+system is essentially fixed for the life of the device.  Primary+examples are devices such as tablets, smart phones, automobile systems,+or even some refrigerators.++The operating system and applications on such appliances may change+over time.  However, the owner of the device will not be able to+arbitrarily change the operating system or firmware installed (unless+they are _really_ clever); in general, this would be fairly strictly+controlled by the device manufacturer.++Operating systems for this use case could include members of the Linux+families (Fedora, Debian, Red Hat, SUSE, and similar).  When a platform+is compliant with the requirements of this use case, it should be+possible to install and maintain the Linux distributions, but modification+or specialization of the OS or firmware may be required.++It should also be possible to use any of the other Unix-based operating+systems and distributions such as those in the BSD family, as well as+commercial operating systems such as Microsoft Windows.  Again, some+modification or specialization may be required.++Real-Time Operating Systems (RTOSs) will play a role here as well,+depending on how the platform is being used.  Whether or not there+is a standard amenable to all RTOSs is TBD.++The stress here is on the idea of _appliances_ -- devices meant to+meet a specific need, with flexible levels of functionality, but+running on a consistent and unchanging set of hardware.+

To me, those boards would fall into the very low end of the general computing category. For instance, the marketing on the Raspberry Pi 4 starts with "Your tiny, dual-display, desktop computer..."

ahs3

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentimage-rs/image-gif

Add changelog for 0.11

 This library provides all functions necessary to de- and encode GIF files.  The high level interface consists of the two types [`Encoder`](https://docs.rs/gif/0.10.1/gif/struct.Encoder.html) and [`Decoder`](https://docs.rs/gif/0.10.1/gif/struct.Decoder.html).-They as builders for the actual en- and decoders and can be used to set various-options beforehand.  ### Decoding GIF files  ```rust // Open the file use std::fs::File;-use gif::SetParameter;-let mut decoder = gif::Decoder::new(File::open("tests/samples/sample_1.gif").unwrap());+let input = File::open("tests/samples/sample_1.gif").unwrap(); // Configure the decoder such that it will expand the image to RGBA.-decoder.set(gif::ColorOutput::RGBA);+let mut options = gif::DecodeOptions::new();+options.set_color_output(gif::ColorOutput::RGBA); // Read the file header-let mut decoder = decoder.read_info().unwrap();+let mut decoder = options.read_info(input).unwrap();

read_info isn't the most obvious method naming here, but I don't think it is a big deal

HeroicKatora

comment created time in a month

PullRequestReviewEvent

pull request commentimage-rs/image-gif

Add changelog for 0.11

I think the README example might still need to be updated for the new Decoder interface?

HeroicKatora

comment created time in a month

PullRequestReviewEvent

issue commentimage-rs/image-png

Forbid unsafe code

I'm in favor of this. Want to create a pull request?

ralpha

comment created time in a month

push eventmit-pdos/ward

Jonathan Behrens

commit sha f7c5047738abe5d7201a90556330a605b87a870b

Fix animation code

view details

Jonathan Behrens

commit sha ccd6ce85fb6496af6b37b19b14a5b6baf154d708

Fix macro conflict

view details

Jonathan Behrens

commit sha 098838bfb6ff91f5002bd46ade9b21b3ef530975

Rename NOFILE to avoid conflict

view details

Jonathan Behrens

commit sha 410a4c0a4d94f836dba2092b08516a4bab2b5c5b

Resolve libcxx warning

view details

Jonathan Behrens

commit sha 8b5357a3aa4e596146e3c54615c426b912ff8a9d

Use clang pragmas rather than GCC ones

view details

Jonathan Behrens

commit sha 8806a1177894c3d1c422a58c577f17ae1d0e40b4

Add specific rule to build sysstubs.o

view details

push time in a month

push eventmit-pdos/ward

Jonathan Behrens

commit sha 8d661069721ea7b27d6ccd8717db9bafb2cc9d44

Improve update_ucode utility

view details

push time in a month

create barnchmit-pdos/ward

branch : detect-bugs

created branch time in a month

PullRequestReviewEvent

push eventmit-pdos/ward

Jonathan Behrens

commit sha f0c9168be6f5541faf6946203a47378a19f96b7c

Allow nsectime() before hpet initialization

view details

Jonathan Behrens

commit sha df2f5810db25669c8253772a7416ed4c4edf4438

Merge initvga and initdoublebuffer

view details

Jonathan Behrens

commit sha 47c938a6ae41ca5910ae6247b5708986ee9a89c4

Fix readme typo

view details

push time in a month

pull request commentimage-rs/image

Add non-consumable equivalent of into_raw to ImageBuffer

I'm not opposed to merging this, but do realize that as_raw provides very similar functionality to the existing Deref implementation. (For the common case of ImageBuffer<Vec<T>>, the difference would be that one returns a &Vec<T> and the other a &[T]).

KernelErr0r

comment created time in a month

push eventmit-pdos/ward

Jonathan Behrens

commit sha aaefc8106ba100dbccb7ea39e404b10bc03f9dc0

Add boot animation

view details

Jonathan Behrens

commit sha 827b1658e6b36a63dc2efb0ff3b04c54352b7877

Improve grub config

view details

push time in a month

push eventmit-pdos/ward

Jonathan Behrens

commit sha c876827aaa3b7819f5e8ac7637d2f7b59be076af

Initialize trap handling earlier

view details

Jonathan Behrens

commit sha eed367a3fa299f936d58e9e3f1052979c9940263

Only clear framebuffer on first call to initvga

view details

Jonathan Behrens

commit sha f4d64575cb6322d4dc07dd5f615c5451dc8b73df

Make UEFI disk images slightly more robust

view details

Jonathan Behrens

commit sha 8499a0b43d781eceae73b47e527874aeb7ef6188

Changes to UEFI, ACPI, and VGA logic to support ASUS ZenBook

view details

Jonathan Behrens

commit sha 7fa0a718fa436735c65c2653e571d99fbd1ac40c

Regenerate grub/grub.efi with latest config

view details

Jonathan Behrens

commit sha d39dcd11c7941cb6193a2d85b1296681d4d31b91

Tweak grub config

view details

push time in a month

push eventmit-pdos/ward

Jonathan Behrens

commit sha de3d2734041476762032b28816d2e8a8330ed065

Include more modules with grub.efi

view details

push time in a month

push eventfintelia/terra

Jonathan Behrens

commit sha bbbbdae9c24f8ef6d7e09c12dc6c6c2a5fac022b

Fix quad-sphere projection, and node priority calculation

view details

Jonathan Behrens

commit sha 49cdc50b513473dfbb20fb426ce0ebaa0a6b3918

Silence logging output

view details

Jonathan Behrens

commit sha 793424feabb4e2024624abfb234e3a030e35542a

Add list of SRTM3 files

view details

Jonathan Behrens

commit sha 29335a273b268e78647db3ef6b99c228097a5b0c

Refactor rshader

view details

push time in a month

push eventmit-pdos/ward

Jonathan Behrens

commit sha 5164e76f95e0686a5b89ca3ee9f08a773b4f9c4e

Fix CI script

view details

push time in 2 months

push eventmit-pdos/ward

Jonathan Behrens

commit sha 945f50527f8ff0b4d97095e7a6c188b6896a2016

Update READMEs

view details

push time in 2 months

push eventmit-pdos/ward

Jonathan Behrens

commit sha cf3a9dc8e47d42136b3632c05a16bb05f1771f26

Make signal state qvisible

view details

push time in 2 months

push eventmit-pdos/ward

Jonathan Behrens

commit sha 75d822c99d6aedd774f44e5346c6ea1fd71add1d

Fix temporary mapping shootdown logic

view details

push time in 2 months

push eventmit-pdos/ward

Jonathan Behrens

commit sha 4998b7b809668e069f11ca3600aa3983279cb6c8

Default to 4 vCPUs and 1GB of RAM

view details

Jonathan Behrens

commit sha 9ebf9447fddb0f6ad7e6613820a7d36e4e56c080

Clean up LEBench code slightly

view details

push time in 2 months

push eventmit-pdos/ward

Jonathan Behrens

commit sha 0c840feb3473e5139a48b8836781f2e8dbc2ed93

Tweak CI script (#64)

view details

push time in 2 months

PR merged mit-pdos/ward

Tweak CI script
+1 -1

0 comment

1 changed file

fintelia

pr closed time in 2 months

PR opened mit-pdos/ward

Tweak CI script
+1 -1

0 comment

1 changed file

pr created time in 2 months

create barnchmit-pdos/ward

branch : ci-xxx

created branch time in 2 months

push eventmit-pdos/ward

Jonathan Behrens

commit sha bcecd6090dceffc2039f73df13ce6530935b5769

Fix CI script

view details

push time in 2 months

push eventmit-pdos/ward

Jonathan Behrens

commit sha 3aee365f49638a9b2c1b6e63f4691edce888df1d

Update ARTIFACT-README.md

view details

push time in 2 months

more