5 ms·

Filip, do you plan to support building the kernel with fil-c? What's the limiting factor right now on supporting that?

by jabedude 10mo ago

pizlonator 10mo ago
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.
- ndesaulniers 10mo ago
  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)."
  - pizlonator 10mo ago
    That won't solve it. Fil-C's memory safety relies on the Fil-C runtime
    - ndesaulniers 10mo ago
      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.
      - pizlonator 10mo ago
        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/fugc - https://fil-c.org/safepoints 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 https://fil-c.org/invisicaps
        ndesaulniers 10mo ago
        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
        pizlonator 10mo ago
        > 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! :-)

Filip, do you plan to support building the kernel with fil-c? What's the limiting factor right now on supporting that?

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.

ndesaulniers 10mo ago
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)."
- pizlonator 10mo ago
  That won't solve it. Fil-C's memory safety relies on the Fil-C runtime
  - ndesaulniers 10mo ago
    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.
    - pizlonator 10mo ago
      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/fugc - https://fil-c.org/safepoints 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 https://fil-c.org/invisicaps
      - ndesaulniers 10mo ago
        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
        pizlonator 10mo ago
        > 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! :-)