> You must have a /mnt/lfs partition mounted at /dev/sda4.
> You must have a /dev/sda4 partition mounted at /mnt/lfs.
> You must have a filesystem, located on the /dev/sda4 device, mounted at /mnt/lfs.
The /dev/sda4 device represents the fourth (primary) partition on the /dev/sda block device, which represents the first SCSI disk.
Fil, you can compile the Linux kernel will clang+lld. `make LLVM=1` https://docs.kernel.org/kbuild/llvm.html
So if I used clang, then I'd have three compilers (yolo-clang, gcc, fil-clang) instead of two (gcc, fil-clang).
Does the fil-c runtime depend on specifics from glibc, or is it that LFS doesn't support building with musl?
> We need to retain the Yolo GCC for compiling the Linux kernel.
Probably can replace that with s/the Linux kernel/glibc/. glibc maintainers have started upstreaming patches for building glibc with clang, but not sure yet what's the latest on that (large) patch series.
No. I could add a flag like that, but that would make my patch to clang larger, which would make rebasing to new clang versions harder.
So I'm choosing not to add such a flag. For now.
> Do you depend on glibc, or is it that LFS doesn't support building with musl?
I support both glibc and musl.
LFS is glibc-based.
For example
> Fil-C supports both musl and glibc. Because of the coupling between the loader, libc, and runtime, Fil-C always uses the same libc in Yolo Land as in User Land. So, when running with musl, we use two versions of musl (one compiled with Yolo-C and another compiled with Fil-C).
> And when running with glibc, we use two versions of glibc (one compiled with Yolo-C and another compiled with Fil-C). The rest of this page documents how the runtime looks with musl. If you build with glibc, you'll see minor differences.
Why do you need a libc compiled with both Yolo-C and Fil-C, and what are the differences? What exactly is Yolo-C?
This project says "The kernel is compiled with Yolo-C."... so is that a good thing? And why not Fil-C?
I see Yolo being mentioned a lot everywhere. What exactly is that, how does it relate to Fil-C, and what are the differences? There is such a thing as Yolo toolchain (and Yolo Land (userland)), too!
It would be nice to have this cleared up somewhere (accessible).
... or maybe I should just ask an LLM at this point.
---
So I did. If anyone is interested in the answer (provided by an LLM), then see: https://chatgpt.com/share/6943df8f-2cbc-8011-9e65-afbcaf1987...
Sanitizers don't have to deal with:
- 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
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
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! :-)
Any idea if it runs on real hardware ?
The only thing standing in the way of it working on real HW is just making sure the kernel is configured properly for it. Like right now the kernel config file is the result of enabling those things that work on the virtual devices that HyperV and VMware provide.
The right answer is modular kernel and something like initramfs and modprobe or whatnot. That kind of work has nothing to do with Fil-C; it’s just distro engineering
At least in this article:
the term "classic C" is still used.
I don't expect for a moment that Fil-C might supplant normal C under normal circumstances. Calling normal C "yolo-C" is dishearteningly pompous. Just because you've invented a C environment with a different tradeoff, people not interested in it are not automatically irresponsible (which is what you are suggesting with "yolo", of course).
I am perfectly fine with Yolo-C nickname.
Now, guarantees…
I’d love to see Rust level intrinsics in gcc now that we have a rust gcc frontend. Improve upon the “RVALUE” crap and actually generate meaningful “oopsies” messages and errors with tips on how to fix. I’d even be ok with gcc + LLM to perform Rust level checking but I digress. Even just making sure footguns become errors is a start and making sure pointer trash is cleaned up is paramount. Even after 30 years I still sometimes forget to include a member variable in the move constructor…