> Dave Airlie just announced in the Maintainers Summit that the DRM subsystem is only ""about a year away"" from disallowing new drivers written in C and requiring the use of Rust.
When the C absolutist maintainers fought for control over the ability to keep Rust out of their ballpark, I didn't expect the reverse to happen.
Still, I think it makes a lot of sense. Completely new GPU drivers are quite rare and the macOS drivers from Asahi are a showcase proving that Rust and GPU drivers work together well. If there's any subcomponent switching to Rust-first for new contributions, it makes sense for it to be the one that had already been proven to be Rust-compatible.
The Rust crustaceans should apply their knowledge to Redox OS and top sending Rust crapware (which it might be fine for security, but Cargo it's a nightmware to maintain) and stop messing with GNU/Linux and, by proxy, the rest of the BSD's.
As tons of distros adopted LibreSSL, it might happen the same with KMS/DRM+MESA as it happened with Xenocara for X.org under OpenBSD and the special X server under NetBSD for legacy machines with really weird adapters leaving out the modular X.org -mainstream- to ports. They might call it VEGA (for MESA) and Iridium (for Gallium middleware).
Asahi project looks barely alive, almost abandoned. I know that their explanation of low activity is that they are being active elsewhere, supposedly pushing all their work upstream, but this has been happening for months and they don't give any reports about their progress, so I'm worried it will all die soon. And given that the project barely brought some Linux compatibility for m1 and m2 hardware and no prospects for bringing similar compatibility for newer generations - I fear it all will be kinda useless in the end.
They inarguably have slowed down, but this should be expected as the project matures. It has also inevitably now faced the time when new generations of contributors are needed as existing ones retire/ move to other projects.
How can it be mature if it can't even boot on newer MacBooks. The slowness does not seem to be due to running out of impactful work that needs to be done.
The new leadership team blogged last year that their priority would be on upstreaming their existing work.
> Our priority is kernel upstreaming. Our downstream Linux tree contains over 1000 patches required for Apple Silicon that are not yet in upstream Linux. The upstream kernel moves fast, requiring us to constantly rebase our changes on top of upstream while battling merge conflicts and regressions. Janne, Neal, and marcan have rebased our tree for years, but it is laborious with so many patches. Before adding more, we need to reduce our patch stack to remain sustainable long-term...
Where do the M3 and M4 fit in? Until upstreaming and CI progress, the core team cannot prioritize new hardware.
I think the majority of that upstreaming work (that isn't on hold until the kernal is ready for the Rust graphics driver to land) has happened and additional features like DP alt mode for USB C have been demoed.
The next update from the team should land on their blog after 6.19 ships
Activity has died down as a result of general Linux kernel developer drama, petty in-fighting, and other factors, but that doesn't change the results they did produce during their most prolific phase so far.
Without proper support from upstream like AMD, Intel, and Qualcomm (to some extent) are doing, Linux will never work as well on Apple's hardware as it does on normal hardware.
Looks believable that they are indeed the devs behind the project, but it's weird to post stuff like that to... reddit? They have a site for the project, why not post there?
> That's been made clear pretty much from the very beginning, that nobody is forced to suddenly have to learn a new language, and that people who want to work purely on the C side can very much continue to do so.
If any C developer developed drivers in C previously for the DRM subsystem, they might in the future be forced to learn Rust.
You're confusing the audience here. That's directed at subsystem maintainers, not just 'anyone who wants to submit a patch'. If a subsystem doesn't want to deal with Rust code, they won't be forced to. But there's no restriction on the inverse.
Whether that's true or false depends on what your hypothetical developer wants to do in the future. When an all-new driver is written in Rust, then working on that driver will require knowing Rust. But nobody's talking about trying to re-write all the existing drivers in Rust, so there will still be plenty of C code to work on even in the DRM subsystem.
That means that, even if a C developer used or added C bindings to DRM when wanting to write a new driver, they would be forced to write their new driver in Rust regardless. That seems to run counter to the promises made by Linus.
Please, stop pluralizing "BSD's", every BSD it's different and OpenBSD only reuses Linux drivers for KMS/DRM; FreeBSD has special layers and tons of drivers ported and NetBSD it's closer to philosophy in design.
So GNU/Linux now it's in the same group as FreeBSD as it has ZFS? Because neither NetBSD nor OpenBSD have it.
OpenBSD doesn't 'rely' on Linux drivers, thanks. Just a shim against KMS/DRM, everything else it's either homegroup or sometimes adapted (back and forth) from NetBSD but OFC patched for correctness and security. There's no ALSA. Pulse it's totally optional. There's no wpa_supplicant except for Eduroam or simlar niche crap under OpenBSD.
OpenBSD has OSS and sndiod. There's Xenocara, an X11 fork.
Again, not Linux, X11, MESA and Gallium are damn generic. Show me the rest of ported Linux drivers into OpenBSD, please.
What is not clear for me, is the purpose of this project. What I could find is that it wants to be a drop-in replacement of PanVK. But since PanVK exists, I fail to see the point. Is PanVK similar to xserver, that is not salvageable? Or is it just RiiR? That's also a fine reason, but I'd expect that more for personal hobby projects.
T-Y-R is also the root in semitic languages (eg, Hebrew and Arabic) related to flying! Maybe not on purpose, but I really like that incidental connection, given the combined reputation of rust and GPU operations for being fast.
Edit: apparently T-Y-R is not a root relating to flight in Hebrew! Maybe other Semitic languages, Im not sure. In Arabic it certainly is
Oh sorry, i thought it was also in Hebrew but it looks like it is not. I would expect the same root to show up in other Semitic languages, but at least in Arabic it’s
ChatGPT claims that the same or similar root does exist in the meaning "bird" or "to fly" in a lot of other Semitic languages. Interestingly, it also claims that there is some correspondence in Hebrew, in the noun תור (tor) that represents a specific kind of bird (turtledove).
> Dave Airlie just announced in the Maintainers Summit that the DRM subsystem is only ""about a year away"" from disallowing new drivers written in C and requiring the use of Rust.
wow
When the C absolutist maintainers fought for control over the ability to keep Rust out of their ballpark, I didn't expect the reverse to happen.
Still, I think it makes a lot of sense. Completely new GPU drivers are quite rare and the macOS drivers from Asahi are a showcase proving that Rust and GPU drivers work together well. If there's any subcomponent switching to Rust-first for new contributions, it makes sense for it to be the one that had already been proven to be Rust-compatible.
I would envision to see some more GPU drivers from Chinese companies like MooreThreads
The Rust crustaceans should apply their knowledge to Redox OS and top sending Rust crapware (which it might be fine for security, but Cargo it's a nightmware to maintain) and stop messing with GNU/Linux and, by proxy, the rest of the BSD's.
As tons of distros adopted LibreSSL, it might happen the same with KMS/DRM+MESA as it happened with Xenocara for X.org under OpenBSD and the special X server under NetBSD for legacy machines with really weird adapters leaving out the modular X.org -mainstream- to ports. They might call it VEGA (for MESA) and Iridium (for Gallium middleware).
> Cargo it's a nightmware to maintain
To my knowledge, the Linux kernel doesn't use Cargo to build Rust code.
Asahi project looks barely alive, almost abandoned. I know that their explanation of low activity is that they are being active elsewhere, supposedly pushing all their work upstream, but this has been happening for months and they don't give any reports about their progress, so I'm worried it will all die soon. And given that the project barely brought some Linux compatibility for m1 and m2 hardware and no prospects for bringing similar compatibility for newer generations - I fear it all will be kinda useless in the end.
> this has been happening for months and they don't give any reports about their progress
This seems a bit exaggerated, their latest progress report is barely two months old: https://asahilinux.org/2025/12/progress-report-6-18/
They inarguably have slowed down, but this should be expected as the project matures. It has also inevitably now faced the time when new generations of contributors are needed as existing ones retire/ move to other projects.
>as the project matures
How can it be mature if it can't even boot on newer MacBooks. The slowness does not seem to be due to running out of impactful work that needs to be done.
The new leadership team blogged last year that their priority would be on upstreaming their existing work.
> Our priority is kernel upstreaming. Our downstream Linux tree contains over 1000 patches required for Apple Silicon that are not yet in upstream Linux. The upstream kernel moves fast, requiring us to constantly rebase our changes on top of upstream while battling merge conflicts and regressions. Janne, Neal, and marcan have rebased our tree for years, but it is laborious with so many patches. Before adding more, we need to reduce our patch stack to remain sustainable long-term...
Where do the M3 and M4 fit in? Until upstreaming and CI progress, the core team cannot prioritize new hardware.
https://asahilinux.org/2025/02/passing-the-torch/
I think the majority of that upstreaming work (that isn't on hold until the kernal is ready for the Rust graphics driver to land) has happened and additional features like DP alt mode for USB C have been demoed.
The next update from the team should land on their blog after 6.19 ships
That's some weird gatekeeping. The hardware they do support is supported well.
Activity has died down as a result of general Linux kernel developer drama, petty in-fighting, and other factors, but that doesn't change the results they did produce during their most prolific phase so far.
Without proper support from upstream like AMD, Intel, and Qualcomm (to some extent) are doing, Linux will never work as well on Apple's hardware as it does on normal hardware.
Wasn't it just a couple of weeks ago that they started supporting M3? That smells like progress to me.
One can start working on creation of a teleportation device. Doesn't mean we have it.
https://asahilinux.org/docs/platform/feature-support/m3/
What do you see as progress here? Nothing is supported, everything is "to be announced" (i.e. unsupported).
they likely meant this progress post showing a desktop booting on an M3 mac: https://www.reddit.com/r/AsahiLinux/comments/1qnddjd/m3_now_... albeit with software graphics
Looks believable that they are indeed the devs behind the project, but it's weird to post stuff like that to... reddit? They have a site for the project, why not post there?
You could read the updates... https://asahilinux.org/2025/10/progress-report-6-17/
Not marketing a not yet complete feature on their website makes total sense. People on internet hating Asahi linux just cause seems like weird to me.
Weren't the old Linux kernel developers promised the opposite by Linus Torvalds? That they would be able to continue writing in C?
https://lkml.org/lkml/2025/2/20/2066
> The document claims no subsystem is forced to take Rust
Dave Airlie is saying that the subsystem maintainers are themselves choosing to move to Rust.
But what about this statement that Linus wrote:
> That's been made clear pretty much from the very beginning, that nobody is forced to suddenly have to learn a new language, and that people who want to work purely on the C side can very much continue to do so.
If any C developer developed drivers in C previously for the DRM subsystem, they might in the future be forced to learn Rust.
You're confusing the audience here. That's directed at subsystem maintainers, not just 'anyone who wants to submit a patch'. If a subsystem doesn't want to deal with Rust code, they won't be forced to. But there's no restriction on the inverse.
I don't believe that I am. Especially given the other arguments and claims in the email.
I'm not seeing any claims in the email which counter my interpretation.
Nothing is happening “suddenly”, and it remains true that “people who want to work purely on the C side can very much continue to do so”.
But, is this true or false?
> If any C developer developed drivers in C previously for the DRM subsystem, they might in the future be forced to learn Rust.
Whether that's true or false depends on what your hypothetical developer wants to do in the future. When an all-new driver is written in Rust, then working on that driver will require knowing Rust. But nobody's talking about trying to re-write all the existing drivers in Rust, so there will still be plenty of C code to work on even in the DRM subsystem.
> When an all-new driver is written in Rust, then working on that driver will require knowing Rust.
But that is not what the claim is about, it is about any new driver, not a specific one.
I think this is true. But that'd be nonetheless up to the subsystem maintainers.
That means that, even if a C developer used or added C bindings to DRM when wanting to write a new driver, they would be forced to write their new driver in Rust regardless. That seems to run counter to the promises made by Linus.
Means that other platforms need to allow Rust in the kernel too in order to use future drivers.
Windows already does, so you’re talking about the BSDs or Darwin?
BSDs and other Open Source OSes that rely on Linux drivers.
Windows probably has not many (or any) drivers ported from Linux.
Please, stop pluralizing "BSD's", every BSD it's different and OpenBSD only reuses Linux drivers for KMS/DRM; FreeBSD has special layers and tons of drivers ported and NetBSD it's closer to philosophy in design.
I will pluralize as all of them port some drivers from Linux
So GNU/Linux now it's in the same group as FreeBSD as it has ZFS? Because neither NetBSD nor OpenBSD have it.
OpenBSD doesn't 'rely' on Linux drivers, thanks. Just a shim against KMS/DRM, everything else it's either homegroup or sometimes adapted (back and forth) from NetBSD but OFC patched for correctness and security. There's no ALSA. Pulse it's totally optional. There's no wpa_supplicant except for Eduroam or simlar niche crap under OpenBSD.
OpenBSD has OSS and sndiod. There's Xenocara, an X11 fork. Again, not Linux, X11, MESA and Gallium are damn generic. Show me the rest of ported Linux drivers into OpenBSD, please.
Are you sure OpenBSD is that dependant GNU/Linux?
What do you mean other platforms?
Also they can just expose c bindings to these rust libraries no?
The old drivers are mostly dual GPL or MIT licenced, they have been used in all the BSD variants.
that is so ridiculous.
> One simply cannot deploy a driver that [...] crashes and takes the user's work with it.
Somebody needs to tell whoever wrote the drivers in the PC where I'm writing this.
I'm sure the volunteers behind those drivers will accept your bug reports.
Don't forget to be as detailed a possible.
What is not clear for me, is the purpose of this project. What I could find is that it wants to be a drop-in replacement of PanVK. But since PanVK exists, I fail to see the point. Is PanVK similar to xserver, that is not salvageable? Or is it just RiiR? That's also a fine reason, but I'd expect that more for personal hobby projects.
Can't wait to write a Rust driver for my eink tablet <3
Oh my, which one?
Interesting to see the building blocks come together. I hope that they can lay foundations that last.
Tyr is a Danish metal band. Period. :-)
I thought Tyr was the Norse god of War & Justice.
Considering that the Mali GPUs were developed by ARM Norway, and this driver is Just, I would say this is one aptly named driver.
Technically they are from the Faroe Islands. Great band, seen them live many times.
T-Y-R is also the root in semitic languages (eg, Hebrew and Arabic) related to flying! Maybe not on purpose, but I really like that incidental connection, given the combined reputation of rust and GPU operations for being fast.
Edit: apparently T-Y-R is not a root relating to flight in Hebrew! Maybe other Semitic languages, Im not sure. In Arabic it certainly is
As a Hebrew speaker I cannot understand how you came into this conclusion. The closest I can think of is ת-י-ר, which is the root of being in a trip.
Oh sorry, i thought it was also in Hebrew but it looks like it is not. I would expect the same root to show up in other Semitic languages, but at least in Arabic it’s
ط ي ر
ChatGPT claims that the same or similar root does exist in the meaning "bird" or "to fly" in a lot of other Semitic languages. Interestingly, it also claims that there is some correspondence in Hebrew, in the noun תור (tor) that represents a specific kind of bird (turtledove).
Indeed, in Hebrew, תור (تور, Tor) is the word for turtle-dove.
Faroese actually