Almost every thread about Rust for Linux ends up with someone saying "why not Zig instead"? And usually the answer is just "it's less mature" or "nobody pushed it".

I didn't know anything about Zig, so I decided to take a look today... and I'm not very impressed ^^;; I learned that Zig does not have:

- Destructors
- Macros
- Lifetimes
- Operator overloading

Those are major reasons why I chose Rust for the drm/asahi driver...

It sounds like Zig is trying to be "modern C"... but the whole point of R4L is to not get stuck with C!

Honestly, I'm kind of sad about Wedson leaving RfL. He developed a huge part of the foundation that made Rust for Linux possible.

I'll still work on DRM (except sched) and driver upstreaming when the core stuff is in place, but I don't know about other subsystems. At the rate things are going, I wouldn't be surprised if upstreaming the drm/asahi driver isn't possible until 2026 at the earliest. I had hopes for things to move much faster, but that's not possible without active cooperation from existing maintainers, and we aren't getting it.

I think people really don't appreciate just how incomplete Linux kernel API docs are, and how Rust solves the problem.

I wrote a pile of Rust abstractions for various subsystems. For practically every single one, I had to read the C source code to understand how to use its API. Simply reading the function signature and associated doc comment (if any) or explicit docs (if you're lucky and they exist) almost never fully tells you how to safely use the API. Do you need to hold a lock? Does a ref counted arg transfer the ref or does it take its own ref?

I regretfully completely understand Wedson's frustrations.



A subset of C kernel developers just seem determined to make the lives of the Rust maintainers as difficult as possible. They don't see Rust as having value and would rather it just goes away.lore.kernel.org/lkml/202408282… When I tried to upstream the DRM abstractions last year, that all was blocked on basic support for the concept of a "Device" in Rust. Even just a stub wrapper for struct device would be enough.

That simple concept only recently finally got merged, over one year later.

🎉🎉🎉 My Linux M1 GPU driver passes >99% of the dEQP-GLES2 compliance tests!!!!! 🎉🎉🎉

Most of this is thanks to @alyssarzg's prior work on macOS, but now I can replicate it on Linux! ^^ @alyssarzg Got some hints from Alyssa, now at 99.3%!

Hello everyone~! Stream starts in 2 hours!!

I'm honestly not too confident about this one... it feels like every time I look at the problem, it looks like something else! Maybe it's time to investigate some related issues and see if they shed any light on the issue? ^^;;

https://twitter.com/LinaAsahi/status/1580444277150056448

Things that might be worth doing:
- Implement tracepoints for GPU stuff instead of printk
- Hook up GPU stats & ktrace to tracepoints
- Look closer at ASIDs
- Write the firmware heap allocator so we can stop leaking firmware objects as a workaround

There's a lot of weird debate about whether Rust in the kernel is useful or not... in my experience, it's way more useful than I could've ever imagined!

I went from 1st render to a stable desktop that can run run games, browsers, etc. in about two days of work on my driver (!!!) All the concurrency bugs just vanish with Rust! Memory gets freed when it needs to be freed! Once you learn to make Rust work with you, I feel like it guides you into writing correct code, even beyond the language's safety promises. It's seriously magic! ✨

Thank you to everyone who watched my XDC2022 talk with @alyssarzg!! I hoped you liked my new witch hat, drawn by the amazing @nana_nono120!🧙‍♀️🪄

We did the whole talk on an M1 Mac Mini running my Rust kernel driver and Alyssa's Mesa driver, using Firefox and @Inochi2D on GNOME!🚀 I'll be keeping the hat on for at least all of October, so make sure to drop by my dev streams if you want to see more of it!! ✨✨

Coming up next, let's see if we can finally work out that pesky TLB invalidation issue!!!!

🦀🐧🍎🔻🧊🇼👩🔥🦊⚙️

Neverball, Firefox + YouTube, and @Inochi2D, in a GNOME Wayland session!!!

All running at the same time, on an Apple M1 Mac Mini with my Rust Linux kernel driver and @alyssarzg's Mesa driver for the M1 GPU!!!

🦀🐧🍎🔻🧊🇼👩🔥🦊⚙️
▶️ For those who haven't been following, I didn't paste myself on top!! That's Inochi2D running my avatar in real time on the desktop session (with a transparent window background)!

Spending the time before the stream making GitHub CI work and fixing Clippy warnings 😊 I really like these! I knew these floats had garbage digits (caused by a round-trip through Python where they became doubles), but I wasn't expecting Rust to help me fix it!

I had a crazy issue with place!() that had me chasing a NULL pointer dereference for a long time... it was a really, really weird corner case!!!

Read on for a crazy Rust unsoundness story 🦀 place!() is a crazy macro I've been developing over the past few days to work around the lack of placement new in Rust. 🤔

It basically takes a pointer and what looks like a struct initializer (even with nested structs!), and then writes each field and sub-field one by one.