I think the way to do that is via something like l4linux, so that the ultra low level bits of the Fil-C runtime aren't relying - circularly - upon kernel functionality compiled with Fil-C that rely on that runtime.

Or perhaps a `--target` flag that says "I'm targeting the linux kernel, not userspace, libcall these symbols (existing kernel functionality) rather than those (glibc interfaces)."

That won't solve it. Fil-C's memory safety relies on the Fil-C runtime

Just as the sanitizers have a runtime, the linux kernel has a re-implementation of those runtimes (the linux kernel does not link libgcc/compiler_rt) and IIRC the compiler will work differently (I forget which flags control that). Prior art here.

The sanitizer runtime is not nearly as complex as the Fil-C runtime.

Sanitizers don't have to deal with:

- https://fil-c.org/fugc

- https://fil-c.org/safepoints

Oh and it's not clear if the current revision of the capability model would work with memory mapped IO: https://fil-c.org/invisicaps

Does fil-c have a way of disabling the capability model for regions of code? (Rust's `unsafe` blocks come to mind).

Maybe if I ask enough stupid questions, you'll get pissed and get the kernel to build/work with fil-c just to prove a stranger on the internet wrong. :P

> Does fil-c have a way of disabling the capability model for regions of code? (Rust's `unsafe` blocks come to mind).

Nope

> Maybe if I ask enough stupid questions, you'll get pissed and get the kernel to build/work with fil-c just to prove a stranger on the internet wrong. :P

I love this attitude! :-)