Currently, the rust panic behavior is to trigger a kernel panic, and all "normal" error handling is done with the Result type. However, in the kernel we have to deal with situations like OOM, which might happen everywhere and typically results in a panic/abort.

An unwinding-based method for handling panics may be possible, with "resource contexts":

1. Before calling into rust, the C code sets up a Context associated with the current OS thread and store it in a global linear map indexed by the current pointer. The Context should include the stack pointer to unwind to on panic, and resource registries.
2. All memory & kernel resources allocated in the rust code are then registered to the Context.
3. If a panic happens during execution, the panic handler reads out the original stack pointer and sets rsp to it. Then, the C code detects that and frees all previously allocated resources.

Unresolved questions:

• How should we associate the Context with the current thread? Global map with current as index works but is expensive. Do we have something like thread-local storage in the kernel?

CommonWA

• URL-based resource management
• Namespace: log
• Namespace: env
• Namespace: resource
• Namespace: runtime
• Namespace: startup

Small request; it's always better to have our GPLs future-proofed, so it'd be nice if this could also be licensed under the GPLv3 and later versions as may arise from the FSF. I know that, linking against the Linux kernel, derived code would need to be GPLv2 to be linked to Cervus anyway. But maybe someday the Linux kernel will also upgrade its license, who knows? :)

To avoid bound-checking every time a memory access happens, we need to make use of the virtual memory - allocate a 4GB continuous virtual address range (maybe from the user space range?) and check access & map pages on-demand.

However, we need to figure out how to hook into the page fault handling process and do the needed work.

Hello there! WASI seems to be a very hot new thing in the WebAssembly world. It's a WASM-outside-web standard from Mozilla which gains more and more support seeing Wasmtime and Wasmer both promising to adopt it.

How does Cervus fit into the picture? Also, what it the status of the project at the moment?

Would be good to have a brief comment in the Readme about Spectre. Is this written assuming that Spectre will be solved in hardware at some future point? Is it only meant for trusted code?

Nitpicking, but the current description is wrong (if you want to follow the naming scheme Microsoft Windows uses). It's the "Windows Subsystem for Linux", not the "Linux Subsystem for Windows".

Currently, we have a lot error types: KernelError, BackendError, IoError and CwaError. This increases complexity and brings inconsistency.

However these error types can be categorized into either "internal error" or "API error", and we can try to reduce them into KernelError and ApiError, before we are ready to finally merge these two types.

Now that we have (blocking) file IO, basic networking can also be implemented :)

Work needed:

• TCP
• UDP
• Raw socket
• Unix socket (?)