How can this be so different from the situation with, say, the nvidia drivers, or even many wi-fi drivers, where it took years of effort from the community before reaching fully working drivers?
And yeah, it helps that there's just a tiny amount of Mac hardware compared to PC hardware. If you get any arbitrary wifi chip to work with Linux, then congrats, you just made like 2 or 3 of the thousands of PC laptops work. But if you get the wifi chip Apple uses in their laptops to work, then you might've gotten wifi to work on multiple generations of Mac laptops.
Bluetooth and WiFi reverse engineering is something I can conceptually grasp from afar, especially because they should be relatively similar across architectures. They are well defined protocols, you send and receive packages. OK.
But GPUs are such complicated beasts, each on it’s own snowflakey way, I don’t even understand how the work on a deep level, let alone imagine how reverse engineering would begin. Memory access and sharing with the CPU, shaders, a massively parallel computing model. Crazy stuff. Oh, and you also get to draw lots of triangles really fast while you’re at it.
In general, I think the porting effort depends on whether Apple has used a freely available industry component. So if the WiFi chip is something that is available in a non-Apple system, one could tweak the AArch64 Linux driver a bit and get it to work on AArch64 Mx Linux. If the silicon is totally custom I can imagine the task being much more difficult.
My guess is that many of the components on which Asahi Linux has made good progress in porting over to work have good support already on vanilla AArch64 Linux. Understanding the integration and working around Apple's proprietary sauce, of course, makes the task totally non-trivial.
> It will probably take many years to reverse engineer.
The last 6% is probably decently hard, but it will probably not be terribly hard to finish - and not long for this team thereafter to change the Python code into an actual Linux driver considering the sheer number of drivers they've already written. Once you have openGLES, you have a HW-accelerated desktop, at least through most desktop environments. Video acceleration is another story they haven't started on, but its generally easy by comparison. Might take another year or two for full OpenGL or Vulkan though.
The actual meat of the "driver" in these case is in Mesa, a userspace component, which is what actually forms and creates the command buffers to send.
You can write a driver to interact with hardware in any language assuming you don't have insane timing requirements. It's mostly a matter of engineering deciding where the pieces should go, though. (For example, everything else aside, a major advantage of this kind of design is that all the real complexity exists in userspace.)
The Linux kernel is written in C, Linus has historically made his dislike of C++ clear as well
Rust would be reasonable but its inclusion in the kernel at this point is "that's a good idea!" rather than "that's a thing being done right now in kernel.org kernels"
Yeah that's precisely what they did. According to this [0] dmesg of a mac mini, M1 macs have the BCM4378 chip, for which they use the existing [1] brcmfmac driver. That driver is years old. A cursory look into git log drivers/net/wireless/broadcom/brcm80211/brcmfmac shows maintenance from various people, including folks with @broadcom.com e-mails, reaching back to 2015 (but that might only have been the date the directory was moved, it might be actually older, as again it's only been a cursory look to establish a lower bound on the age). They did have to add some patches to add support for the specific chip used by apple thogh, which they are upstreaming [2], but they weren't starting from scratch.
[0]: https://gist.github.com/z4yx/13520bd2beef49019b1b7436e3b95dd...
[1]: https://wiki.debian.org/brcmfmac
[2]: https://lore.kernel.org/lkml/4928ea79-2794-05fb-d1a8-942b589...
You linked to the old Corellium patch, here's proper one: https://lore.kernel.org/linux-acpi/20211226153624.162281-1-m...
For the core of the driver that may be true. Ultimately the driver needs to _interface_ with the platform (and the OS) and for that custom code needs to be done to account for platform and OS differences. You cannot abstract away everything.
They only have to get a single device model to work, with perhaps a handful of small variations. Monoculture has its benefits.
So I would assume it's mostly developer resources that make the difference.
Support for Apple Silicon has much less device combinations to deal with unlike what you see with other devices. There is only one type and fixed set of GPU, storage, wifi, bluetooth drivers to support vs the hundreds of hundreds of GPU variants, with the infinite combinations of other devices found on PCs.
Also the so-called 'open-sourcing' of the Nvidia drivers which got the Linux fans too excited, only to be disappointed to realise that Nvidia was not only still working against them, but the news of this announcement turned out to be a red herring.
Pushing GPU FFI wrapper code to binary blobs is still not 'open-source'.