aboutsummaryrefslogtreecommitdiff
path: root/book/en/src/rtic_vs.md
diff options
context:
space:
mode:
authorbors[bot] <26634292+bors[bot]@users.noreply.github.com>2023-05-23 06:26:28 +0000
committerGitHub <noreply@github.com>2023-05-23 06:26:28 +0000
commit62162241d4c7d82dfbb310113f7525d134cfde9b (patch)
tree4346cbe248835eba381003d8592248102028dac5 /book/en/src/rtic_vs.md
parent21b0d97e17922c023a3b5d8148a414d4277f7b87 (diff)
parent9fa073f7936782bddf5d02b7b1949032e84de1bd (diff)
Merge #741
741: Docs 2 r=korken89 a=datdenkikniet Working on the migration guide and other docs TODO: - [x] Migration guide - [x] Hardcoded examples should link to example code that is tested (this was already done, AFAICT) - [x] Address #699 - [x] Discuss: should we remove references to non-v2, apart from the migration guide and link to the book for v1? (Off-github conclusion: yes) - [x] RTIC {vs,and} Embassy (important: distinction between embassy runtime & HALs) - [x] More descriptive docs on how to implement & PR implementations of `Monotonic` to `rtic-monotonics` Co-authored-by: datdenkikniet <jcdra1@gmail.com>
Diffstat (limited to 'book/en/src/rtic_vs.md')
-rw-r--r--book/en/src/rtic_vs.md6
1 files changed, 2 insertions, 4 deletions
diff --git a/book/en/src/rtic_vs.md b/book/en/src/rtic_vs.md
index 454b239..9d6f4f2 100644
--- a/book/en/src/rtic_vs.md
+++ b/book/en/src/rtic_vs.md
@@ -4,8 +4,6 @@ RTIC aims to provide the lowest level of abstraction needed for developing robus
It provides a minimal set of required mechanisms for safe sharing of mutable resources among interrupts and asynchronously executing tasks. The scheduling primitives leverages on the underlying hardware for unparalleled performance and predictability, in effect RTIC provides in Rust terms a zero-cost abstraction to concurrent real-time programming.
-
-
## Comparison regarding safety and security
Comparing RTIC to traditional a Real-Time Operating System (RTOS) is hard. Firstly, a traditional RTOS typically comes with no guarantees regarding system safety, even the most hardened kernels like the formally verified [seL4] kernel. Their claims to integrity, confidentiality, and availability regards only the kernel itself (under additional assumptions its configuration and environment). They even state:
@@ -16,7 +14,7 @@ Comparing RTIC to traditional a Real-Time Operating System (RTOS) is hard. First
[seL4]: https://sel4.systems/
-### Security by design
+## Security by design
In the world of information security we commonly find:
@@ -30,4 +28,4 @@ Thus their claim is correct, security is completely out of hands for the OS, the
RTIC on the other hand holds your back. The declarative system wide model gives you a static set of tasks and resources, with precise control over what data is shared and between which parties. Moreover, Rust as a programming language comes with strong properties regarding integrity (compile time aliasing, mutability and lifetime guarantees, together with ensured data validity).
-Using RTIC these properties propagate to the system wide model, without interference of other applications running. The RTIC kernel is internally infallible without any need of dynamically allocated data. \ No newline at end of file
+Using RTIC these properties propagate to the system wide model, without interference of other applications running. The RTIC kernel is internally infallible without any need of dynamically allocated data.