Comment by gsck
10 months ago
I'm not sure about why they are upset with the issue of upstreaming the changes into the kernal.
They want to upstream drivers for a device that the creator of clearly has no interest in allowing others to use outside of their walled garden. The knowledge around it is from a massive , albeit impressive, RE effort.
Who is going to support it? Where is the demand for it? It would be different if Apple were to provide patches and drivers for their own hardware, at least then you know there is a vested interest in supporting the hardware from the people who know it better than anyone else and have the means to continue supporting it.
I applaud Hector and everyone else that contributes to Asahi, its genuinely a cool project and the progress they have made is insanely impressive given the lack of any official documentation about the hardware they are working on, but its one of these things that will remain in the realm of a cool curiosity much like running Linux on a games console.
You should click through some of the links to see where the clashes actually happened. It didn't have anything to do with the actual hardware support. Rather, it was over stupid shit like the kernel DMA team throwing a hissy fit over the idea of there being Rust bindings for the DMA interface: https://lore.kernel.org/lkml/20250108122825.136021-3-abdiel....
When the response to such a small contribution is just "No rust code in kernel/dma, please" with a complete shutdown of any attempt to discuss alternatives, it's kinda pointless. Even though Rust is supposed to be an allowed language in the kernel now, with blessing from Linus himself, there's apparently just submaintainers of critical, highly shared infrasture that outright refuse it.
So this has nothing to do with "who will own the Apple drivers?!" but just the rest of the kernel going "your integration layers are an affront to our Holy C, begone religious heretics!"
"No rust code in kernel/dma, please" is a totally reasonable request though, once again it comes down to who supports it? When 99% of the kernel is written in C it makes sense to keep it C.
If you start introducing new languages that most maintainers are not anywhere near as familiar with, you create an unmaintainable mess.
Linux isn't a hobby project anymore, its critical infrastructure. You can just introduce changes because a few people think its cool.
Rust in Linux has official blessing. 99% of the kernel being in C is irrelevant, it's not a C-only kernel anymore officially.
But since the patch didn’t include any code in kernel/dma, it comes across as “I didn’t even read the patch.”
Agreed, supporting apple devices is going to be a maintenance nightmare as it goes against the wishes of apple. At best, apple involuntarily makes reverse incompatible changes which breaks the drivers and at worst apple specifically sabotages the drivers to keep people in the walled garden.
This may be controversial but you also don’t have a right to merge in code to the kernel. If the maintainers don’t want rust code then you should write your drivers in C. And if you don’t like that you can maintain your own kernel tree in rust and take on the maintenance burden.
> Agreed, supporting apple devices is going to be a maintenance nightmare as it goes against the wishes of apple. At best, apple involuntarily makes reverse incompatible changes which breaks the drivers and at worst apple specifically sabotages the drivers to keep people in the walled garden.
Apple explicitly chose to provide a way to boot third-party operating systems when designing how the M-series SoC boots. Their SoC stuff dates in some components AFAIK back to the very first iPod SoCs in its design.
I would understand that attitude if someone wished to, say, upstream code for PlayStations or other game consoles because that is a bunch of fights waiting to happen, but Apple hasn't made any move directly against FOSS OSes on their computers in the past and there is no reason to believe that will change.
Great, so you boot your custom OS, and you can... I guess display a terminal and maybe talk to the disk? How do you use the hardware without drivers? Did Apple document their hardware interfaces?
3 replies →
> Apple explicitly chose to provide a way to boot third-party operating systems
And they explicitly chose against a UEFI interface like prior Macs, which would have actually enabled proper Linux support. Now you have poor people trying to reverse-engineer a Devicetree from scratch to get basic features to kinda work, emulating hardware features in software and working with no documentation from Apple. They "explicitly" chose to expose iBoot because otherwise you wouldn't be able to reinstall MacOS in a full data loss situation.
By comparison - reverse engineering an unsupported AMD or Intel CPU would at least give you some basis to work off of. You have UEFI as standard, ACPI tables provided by hardware, even CPU documentation and Open Source drivers to work off of most the time. Asahi shot themselves in the foot by trying to support hardware that doesn't support them back. You can argue that Apple was conspiring to help, but we have no actual evidence of that.
> Their SoC stuff dates in some components AFAIK back to the very first iPod SoCs in its design.
And none of those platforms ever got proper Linux support either. I love Linux as much as the next nerd, but it doesn't seem wild to suggest that Apple Silicon will never have feature-complete Linux support. And for many people, maybe that's okay!
> a device that the creator of clearly has no interest in allowing others to use outside of their walled garden
This doesn’t seem accurate.
> In macOS 12.1, Apple has added the ability to directly boot a raw image directly instead of a Mach-O, even though Apple has absolutely no use for this functionality. According to Hector Martin (Asahi Linux developer) making things easier for Linux developers is the only known reason Apple would have added this.
https://linustechtips.com/topic/1396740-apple-adds-feature-i...
> Where is the demand for it?
There was at least one person who said[0]:
"I'd absolutely love to have one, if it just ran Linux.. [...] I've been waiting for an ARM laptop that can run Linux for a long time. The new Air would be almost perfect, except for the OS."
Seems like the same person has even used Asahi to make a Linux kernel release[1][2].
But Linux presumably doesn't have the resources to go chasing hardware platform support based on the whims of a singular Linux kernel developer/maintainer/creator.
----
[0] https://www.realworldtech.com/forum/?threadid=196533&curpost...
[1] https://lore.kernel.org/lkml/CAHk-=wgrz5BBk=rCz7W28Fj_o02s0X...
[2] via: https://arstechnica.com/gadgets/2022/08/linus-torvalds-uses-...
I also think it would be cool to run Linux on my MacBook. But that alone isn't reason enough to add support for it.
Linux runs on over 90% of all production servers on the planet, think about that. If you introduce a change it needs to work and be maintained, if you add something but then later realise you dont have the resources to maintain it you can't remove it. You have created more work for yourself. Relevant xkcd https://xkcd.com/1172/
This quite literally the story of nouveau. The driver exists because people need it, and the driver is maintained by the people who wrote it. I don't see why the same doesn't apply to Linux on Apple Silicon.
Yes but how many nvidia graphics cards are there in circulation? I'd say infinitely more than there are Apple M1/2/3/4 chips in the wild.
is nouveau written in Rust?
No. However its replacement (Nova) is.
1 reply →
linux on game consoles might be a small part of the market, but it's a reality. there's a fair amount of manufacturers, devices and people buying them.