Add terminology and boundaries RFC #2
Conversation
| proposes we define the following terms to refer to parts of our OS, adapted | ||
| from [EROS](https://web.archive.org/web/20160412201504/http://www.coyotos.org/docs/misc/eros-structure.pdf): | ||
| the _kernel_, which implements threading and inter-proces communication (IPC) | ||
| as a wasm module, the _nucleus_, which implements a small wasm JIT natively, |
There was a problem hiding this comment.
Just to be clear, the kernel will be a wasm module that runs on the nucleus?
There was a problem hiding this comment.
Yes, this has been clarified in my latest revision.
| from [EROS](https://web.archive.org/web/20160412201504/http://www.coyotos.org/docs/misc/eros-structure.pdf): | ||
| the _kernel_, which implements threading and inter-proces communication (IPC) | ||
| as a wasm module, the _nucleus_, which implements a small wasm JIT natively, | ||
| and the _firmament_, which specifies IPC interfaces for drivers to implement. |
There was a problem hiding this comment.
Is the firmament an actual "thing", or just a way to define interfaces between drivers and processes?
There was a problem hiding this comment.
The firmament would be the equivalent of the syscall boundary in a traditional OS.
| RFCs. | ||
| - The _nucleus_, which implements a small WebAssembly runtime in native code. A | ||
| nucleus will implement the minimal set of hardware interfaces required by the | ||
| kernel and will likely resemble an exokernel on its surface. A nucleus need not |
There was a problem hiding this comment.
Good call about the exokernel-like interface
| The Nebulet operating system architecture is defined in terms of four | ||
| components: | ||
|
|
||
| - The _kernel_, which implements the core functionality of a microkernel OS: |
There was a problem hiding this comment.
Can you be clearer about whether the kernel is a wasm module or not?
|
|
||
| interface EthernetNic { | ||
| fn send(&mut self, pkt: EthernetPacket) -> Result<()>; | ||
| fn send_inplace(&mut self, func: impl Fn(&mut EthernetPacket) -> Result<()>) -> Result<()>; |
There was a problem hiding this comment.
I'm curious how send_inplace would work. The user supplies it a function that takes a EthernetPacket reference?
There was a problem hiding this comment.
See link for an example of a similar function. The idea here is that the network driver can allocate a packet located inside its Tx queue, then the application modifies the packet.
https://github.com/libpnet/libpnet/blob/master/pnet_datalink/src/linux.rs#L231
There was a problem hiding this comment.
Oh interesting! I hadn't thought of that. It'd be difficult to get the packet into the other wasm linear memory without copying, but could be possible through page flipping.
| # Drawbacks | ||
| [drawbacks]: #drawbacks | ||
|
|
||
| Implementing all drivers as WebAssembly applications may not be able to provide |
There was a problem hiding this comment.
This is an important thing to think about. I'm leaning towards being able to dynamically load (or at startup only, depending on the security model) clif ir for drivers without sandboxing overhead, but this remains to be seen.
There was a problem hiding this comment.
As someone with both a security and networking background, I would argue in favor of statically-compiled drivers, with the nucleus implementing the firmament. That said, I wonder if we can somehow have it both ways.
There was a problem hiding this comment.
Okay, I'm okay with that. I suppose recompiling the nucleus for each different use-case is fine.
| thread/process scheduling and isolation, and inter-process communication | ||
| (IPC). These two pieces of functionality will be further specified in future | ||
| RFCs. | ||
| - The _nucleus_, which implements a small WebAssembly runtime in native code. A |
There was a problem hiding this comment.
If the nucleus is to contain the webassembly compiler and runtime, which are largely architecture independent, should we break it up further? That is, into the compiler/runtime and the HAL?
There was a problem hiding this comment.
Good idea. Another boundary, yay!
moosingin3space
force-pushed
the
master
branch
from
5a9685b to
0fa154f
Compare
|
Thinking about it again, I'm attempting to figure out how we'd implement a microkernel in wasm. So, obviously, it would use the nucleus' hal interface and whatnot, but still. Where is that line drawn? I think it's a good idea to split up the components, but the kernel should be native. |
moosingin3space
force-pushed
the
master
branch
from
0fa154f to
5e8df78
Compare
Rendered