The SerenityOS Project is a hobbyist Unix-like/ELF desktop operating system with support for x86_64 and (WIP) aarch64 platforms. The project was started in 2018, and initially used a GCC patchset to bring up the cross-compilation environment. Since August 2021, we have maintained an llvm patchset to add a target triple, driver file, and support in libc++ for building the OS.
Compiler Support
The support for building the OS with either a GCC or Clang based toolchain are roughly equivalent at this point. We compile the entire OS stack in both Github Actions and Azure DevOps using both Clang and GCC and run a test suite in QEMU on every main branch commit and pull request.
In the summer of 2022, I upstreamed our CMake support, which made it into CMake 3.25.
I have been tracking the progress of upstreaming toolchain related patches to the various open source projects here on GitHub. Our patches are already upstream for config.sub, config.guess, and CMake.
Why?
Upstreaming the patches we have to LLVM, gcc, and binutils is the next step in upstreaming the rest of the patches in our Ports tree to be good FOSS citizens.
We undertake a ritual each LLVM and gcc release to rebase our patches on top of the latest release, which takes time away from developing parts of the operating system, test infrastructure and developer experience. Upstreaming the patches to LLVM would allow us to better dogfood upcoming LLVM changes, and reduce the impact that regressions have on our update process. The entire operating system is written in C++20, with custom libraries for everything from the Kernel to the C library to the Windowing system. Developers such as Daniel Bertalan have been very proactive in reporting trunk regressions in our core OS libraries to date. Having the patches upstream would make testing trunk changes much easier and more automate-able.
There is also some interest from external projects. The nixpkgs project [1] has expressed interest in supporting our Ports, but they are uncomfortable with the non-upstreaming of many of the patches we have. Contributors to the Zig language have expressed interest in supporting SerenityOS as a target, but the lack of upstream llvm support makes them carrying our patches a non-starter. A similar situation exists for Rust, where there are people interested in a Rust port to Serenity (which I made into a port [2] a few months ago). However, without support in upstream LLVM, adding support to rustlang/rust and rustlang/rust-libc is going to be a non-starter. And without at least a stage-1 rust port, no low level rust crates will be willing to add #[config(os_name == "serenity")] patches to allow porting more complex rust programs to the system.
Who?
SerenityOS has a robust contributor base, with ~900 contributors, ~1000 commits merged per month, and ~50 regular contributors each month. The set of core developers who work on toolchain changes is a bit smaller, and generally consists of myself, Daniel Bertalan, Tim Schumacher.
What?
We would like to upstream the 12 patches or so that comprise our llvm patch set. This will hopefully decrease the friction of toolchain updates, help encourage more SerenityOS developers to engage with the LLVM community, and allow for downstream projects to have an easier time justifying incorporating patches to support SerenityOS.
I’m looking for feedback on the feasibility of upstreaming the patches I linked at the top of the post, and any infrastructure-related requirements that the project would be responsible for should the patches be accepted.
Extra links, since I’m only allowed 5
[1] nixpkgs: https://github.com/NixOS/nixpkgs/pull/186484#issuecomment-1608960696
[2] rust port: https://github.com/SerenityOS/serenity/pull/15935/files