ethindp
Figure out kernel driver interface
Currently everything is compiled directly into the kernel. This is a very unfeasible design since the kernel binary (in both debug and release) is quite large already, and building every driver into the kernel would make a prohibitively large binary that wouldn't fit on any ESPs.
Though we have no drivers yet, the above point still holds, so this issue is technically two parts.
- Part 1 is identifying how drivers will function. This kernel aims to be a microkernel but I understand that not everything can be in userspace, though we should make an effort to do so.
This includes questions like:
- Identifying the kernel/driver interface;
- Identifying the binary format that drivers will be in (ELF, WASM, a scripting language, ...);
- And, of course, writing the drivers themselves. If the drivers are in a compiled form, then we'll need to incorporate that into the build process.
- Part 2 is writing the drivers in userspace. This includes things like:
- what system calls the drivers will use;
- whether we should implement some kind of authentication mechanism to prevent random programs from accessing devices; and
- how applications can communicate with drivers.
This issue handles part 1. We'll handle part 2 in another issue (TBD).
My initial idea was something like this, at least for the binary format part: drivers would run as web assembly modules. I considered the idea of a scripting language (perhaps something like Rhai) but the author noted that the language would most likely be too slow for device drivers. This hasn't been tested though and maybe Rust can do some fancy optimizations to make it fast enough. But web assembly modules seemed like one of the best options:
- The kernel would have absolute control over the execution environment and the functions (external imports) available to Wasm modules.
- Wasm modules can be written in practically any programming language in existance. This makes the kernel modules language-agnostic -- just dump them in and off you go.
- Wasm modules are reloadable without needing to do any trickery or monkey-patching that you'd need to do for ELF programs.
On the other hand, ELF/PE/MACHO is also a good option, though it would be a lot more complex. But its advantages are things like:
- A real executable binary can be produced by practically any compiler ever developed in computer history. A Wasm module is pretty universal but not as universal as a real executable image.
- An executable binary can be directly loaded and linked into the kernel. All we'd need to do is export a C-compatible interface and write C headers for it.
- An executable binary would be able to use pointers and other language features without needing to go through the kernel (this is both a blessing and a curse).
