6 months in, we have a booting xnu kernel! #554
Replies: 1 comment 8 replies
|
Very cool @mszoek I am really looking forward to this. Only one question I keep thinking, why not work with PureDarwin? |
|
Rest in Peace CliffðĨ |
|
mszoek... sik OS name...you're a legend!! and Video: So with the move from FreeBSD to Darwin shall we expect the loss of significant hardware compatibility? Would love to just buy/use custom picked hardware and install macOS on it and have all hardware just work because FreeBSD has may drivers. If the project is Darwin will there be any hope to use above mentioned hardware? anyway bigup yerself, hope this project is a success and Elon steps in to fund it ;-) |
Out of curiosity, I have also spent some time looking into hardware support and the Darwin kernel. As a long-time Hackintosh user, I would consider myself a technically inclined person with a solid understanding of the subject, though certainly not a kernel developer. Therefore, please forgive me if some of my statements are somewhat simplified. Yes, FreeBSD comes with a large number of drivers. However, the operating system was originally developed primarily for server environments. As a result, some workstations may already function quite well with the available base drivers. Macs, however, are often not ordinary workstations and require specific ACPI adjustments as well as hardware-specific drivers to ensure that features such as sleep, wake, and suspend work reliably and that the hardware is properly exposed to the operating system. MacBooks in particular require numerous chipset- and platform-specific optimizations. When it comes to drivers themselves, FreeBSD stores them in system directories within the root filesystem, similar to Linux. The real challenge, however, is not where the drivers are stored but the driver model itself. macOS, or more specifically Darwin/XNU, uses its own driver framework called IOKit. Most drivers are implemented as so-called Kernel Extensions (.kexts) and do not follow the traditional Linux or Unix driver architecture. If I understand my research correctly, the developers of ravynOS need to provide IOKit drivers or compatible kernel extensions for many hardware components. Even when functional Linux or FreeBSD drivers already exist, they cannot simply be reused without modification. This is where a significant amount of development effort and specialized expertise is required. In my opinion, it would make sense for the project to focus initially on virtualization and prioritize the drivers and core components required for that environment. Once a stable foundation has been established, support for real EFI-based hardware could be expanded gradually, for example to systems from around 2015 onward. Perhaps mszoek can provide some additional insight into the current development strategy. I would be particularly interested in learning more about the project's current priorities and the long-term roadmap for hardware support. |
|
U mean virtualisation to make IOKit possible, to make untweaked BSD/Linux drivers possible, or to make tweaked BSD/Linux drivers possible? Imo, sharing at least 1 driver model is needed tho thrive in the early phase (if not coming inside vSphere or a disk image). |
|
Thanks for the kind words! Would love some funding for sure :)
Exactly right. We have IOKit and I'm working on IOHID currently (which is large and complex). This will complete the IO needed for a basic console system and help me build out userspace. I wrote a really simple AHCI driver and stuff needed to support QEMU VMs for now, so that is the initial target. I'm trying to build a bootable VM image with enough CLI tools that the shell is somewhat usable as our first Darwin proof of concept. So far, it boots to "init" (i.e. my fake launchd executable). Dyld works, libSystem is there (mostly), text can be printed on screen via stdout, etc. What we're missing right now is input which is where IOHID comes in (keyboard, mouse). Longer term: FreeBSD has a cool trick. Its linuxkpi module exports enough of the Linux kernel interfaces for some drivers (mostly WiFi ones) to build as FreeBSD driver modules. I plan to do something similar as a kext eventually so we can port Linux drivers into a bundle. It's not perfect but will hopefully close the gap until we can write proper native ones. |
Uh oh!
There was an error while loading. Please reload this page.
I started working on the Darwin port in Oct 2025 and it's now April 16. In that time, I've written a simple EFI bootloader for our XNU kernel, an ACPI Platform Expert, AHCI driver kext, ported and built countless tools and libraries, wrote a kernel prelinker tool and ported enough of the stack to have everything cross-building on Linux. We have a ravynOS SDK and a toolchain bundle that can be replicated per host platform. I mined deep and slayed a couple of balrogs down there.
And now, after all that, we have a booting XNU kernel that is ready to run userspace on a QEMU Q.35 virtual machine, AHCI SATA disk, HFS filesystem with EFI bootloader. Yay!! <3
Now... this is very proof of concept, and that's all. My drivers only match ICH9 controllers. I'm very sure stuff is missing from my PE. The console is not real IOGraphics, just a stub IOFramebuffer that uses the EFI GOP framebuffer to display, like I did in FreeBSD. The bootloader hardcodes the UUID of the root filesystem. There's a lot left to do. This is the starting point.
All reactions