Some of Dusk's goals, such as being able to visualize PDFs, imply a big chunk of code has to be written for them. 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 existing code as much as possible.
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: on 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 into a particular piece of UNIX C code before it can be compiled and run by Dusk.
Dusk' big bet is that with that compiler, it will be possible, with a minimal effort, to piggy-back on existing UNIX code to provide the same logic in a much simpler environment.
Another pile of code worth leveraging is existing device drivers written in C. The problem with those is that they're typically deeply intertwined with their host kernel abstractions and those abstractions are typically too complicated to be a good fit to Dusk, making the porting effort very difficult.
I took a stab at porting NetBSD's drivers, with modest success, but the crap I have to wade through seems too much, relative to the end result, to be worth it.
Then I took a better look at Plan 9. You know how you sometimes hear people saying that Plan 9's code is clean? It's true! Compared to NetBSD's code, to paraphrase Linus, it's a work of art. Cleaner abstractions, grokkable code.
So I began porting that code instead. So far it's a smooth sailing. But I know there's a big challenge ahead and it's...
All modern OSes having a wide support for hardware (and thus being a good source of code to leverage) support pre-emptive multitasking, including Plan 9.
This means that driver logic is littered locking logic, which we can get rid of, but also with "sleep for a bit, waiting for some condition to happen on the hardware side" bits and pieces of code. This can be ported to Dusk just fine... but will make the system jittery!
Once that porting is done, an extra challenge will be to transform that driver into "async style" code where instead of waiting (except for very small waits. sometimes, it's just "security wait to make sure the hardware had the time to acknowledge that register write"), we return. This means we'll have to keep track of "execution status" to know where we need to return to once the Dusk's idle loop is ready to give its attention to that particular driver again.
So, that's a lot of work, beggin the question of whether it's worth porting driver code at all. The answer there is, as always, "it depends". Some drivers, such as a USB stack, have a really big list of "business logic" that you don't want to re-implement yourself, so it's worth pouring the "asynching" work.
Sometimes, hardware documentation is not publicly available, so the only actual source of information about that piece of shit hardware is in the form of code. Guessing hardware specs from code is not fun, one might as well reuse the code entirely, even if that means "asynching" work.
In other cases, I guess it will make more sense to write the driver from scratch. When the specs are clear, that there is little "business logic" on top of it, why bother?