Author: Virgil Dupras <firstname.lastname@example.org>
Date: Thu, 20 Oct 2022 12:22:36 -0400
doc: add design/port
2 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/README.md b/README.md
@@ -8,6 +8,11 @@ computers anymore but that there's still many modern computers still around.
It does so by aggressively prioritizing [simplicity][simplicity] at the cost of
+Dusk OS innovates (well, *will* innovate) by having an ["almost C"
+compiler][duskcc] allowing it to piggy-back on UNIX C code, through a modest
+[porting effort][port], to reach its goals and stay true to its design
+constraints with a minimal effort.
## Why build this OS?
Most modern operating systems can do all whatever we want to do. Why do we need
@@ -112,7 +117,7 @@ The high level roadmap for Dusk OS is:
capable of compiling a nice subset of C. For example, it can compile Collapse
OS C VM. You can see the kind of code that Dusk is capable of compiling and
executing at [fs/tests/cc/test.c] and you can read about its
- [technical details].
+ [technical details][duskcc].
* It can run bare metal on some PCs (and QEMU, of course). It has drivers (in
various state of sophistication) for:
* VGA in text mode
@@ -141,7 +146,7 @@ So, there's a fair chunk of work left, but there's also a lot that's already
It's also important to note that, by design, this C compiler departs from ANSI
-standard in some ways, described in its [technical details].
+standard in some ways, described in its [technical details][duskcc].
Development happens on [sourcehut].
@@ -228,9 +233,11 @@ BIOS" mode.
diff --git a/fs/doc/design/port.txt b/fs/doc/design/port.txt
@@ -0,0 +1,29 @@
+# Porting UNIX code to Dusk
+Some of Dusk's goals, such as being able to visualize PDFs, implies a big chunk
+of code has to be written for it. The Forth ecosystem have a few chunks of logic
+here and there, but Forth being Forth, nothing is standardized and, more
+importantly, it's nowhere near the UNIX ecosystem in terms of completeness.
+We don't want, however, to embark on an endless journey of reimplementing this
+logic. We want, instead, to be able to piggy-back on the exiting code as much as
+Therein lies a problem: that code is written on top of a UNIX platform, a
+platform which we reject because of its complexity (see doc/design/limits). How
+to reconcile these conflicting goals?
+First, by counting on the fact that most of the tricky logic we want to
+piggy-back on is "pure" logic and doesn't actually depend on the UNIX platform.
+Second, by counting on the fact that the most important pieces of logic out
+there are written in C.
+Third, by creating an "almost C" compiler that tries to strike a good balance
+between two conflicting goals: one the one side, stay true to Dusk OS design
+goals and on the other hand, minimize the amount of work that has to be poured
+on a particular piece of UNIX C code before it can be compiled and ran by Dusk.
+Dusk' big bet is that with that compiler, it will be possible, with a minimal
+effort, to piggy-back on exiting UNIX code to provide the same logic in a much