Asahi Lina with the Asahi Linux project was successful in the Rust DRM driver efforts on the Apple M1 SoC to get GNOME running, Firefox with YouTube video playback, the game Neverball, various KDE applications, and more.
This is some great progress especially with the driver being written in Rust – the first within the Direct Rendering Manager subsystem – and lots of work there with the Rust infrastructure in early form. It won’t be until at least Linux 6.2 before this driver could be mainlined while we’ll see how quickly it tries to go mainline before it can commit to a stable user-space interface. At the moment there is also a significant driver “hack” involved but will hopefully be sorted out soon. Over in user-space, the AGX Gallium3D driver continues being worked on for OpenGL support with hopes of having OpenGL 2.1 completed by year’s end. Obviously it will be longer before seeing the Apple graphics suitable for modern gaming with Vulkan, etc but progress is being made across the board in reverse-engineered, open-source Apple Silicon support under Linux.
I don’t think we would have a problem with Rust based drivers, except for the build system configuration. My suggestion would be to do the driver as a package that the final haiku image would import.
And we need to find someone who wants to maintain it as most of us might prefer C++.
I am also not a fan of rust, but Asahi Lina has arguments, so if its possible to have rust in the kernel, at least for this, I would not disallow it. But I am only a fanboy
Personally I think in the Haiku source repository, we should stick with C++ because that’s the language the team knows, and we’ll be the ones maintaining the code there.
However, from the software design side, there are ways to write a driver in C or other languages that can bind to C, and if someone wants to work on making it easier to write drivers in Rust, we have no problems with that and are happy to merge the relevant changes on our side. The driver would have to be a separate package maintained by someone else, but on Haiku that’s not as much a problem as it is in Linux. In Linux, the project os really organized in a way that it’s a lot easier to have your drivers in-tree with the Linux kernel. They often change internal interfaces, and when they do so, they will update the drivers that are in Linux main git tree, but if you driver is outside that repository, you’re on your own.
In Haiku, the interface between the OS and drivers is more well-defined and changes less often. So it is more easily possible to keep your driver elsewhere than the main repository.
Now, writing a driver in Rust for Haiku is completely untested, but sounds fun to explore for someone who likes both Haiku and Rust, and I’d be happy to see someone explore that. I’ll provide help where I can, depending on my available time and knowlege. Just don’t expect me to maintain the Rust code in the future because I’d have no idea about how to do that.
