$ zgrep CONFIG_DRM_PANIC_SCREEN_QR_CODE /proc/config.gz
  CONFIG_DRM_PANIC_SCREEN_QR_CODE=y

(I would agree the first argument is kinda wavy. If anything the panic handler has a fairly unique relationship with memory safety: it's likely to be executing in an environment where that's already gone out the window and it needs to try to assume as little as possible about what might or might not be correct that its reading from and writing to, while also its own memory safety is perhaps less critical because the system is already crashing, it's just got to get the info out before everything completely stops. Though that doesn't make it immune from security concerns. A code execution vulnerability in the handler means any panic could turn into a worse problem)

> There is no particular reason to do it in rust, I just wanted to learn rust, and see if it can work in the kernel.

Which I think is fairer. Good on him for trying to stay on top of recent developments. With Linux basically supporting Rust now so it's a valid choice, especially for a new component. Plus, it's not like this is an important features, the anti-Rust people can live perfectly fine without QR code crash dumps like they have for decades now.

I think doing this in C is an unnecessary risk (you really don't need all that many raw pointer interactions and shared struct ownership) but the security and stability of this component hardly matters. The kernel is already dead because of a bug or a hardware failure anyway, this is just making the catastrophic failure of the rest of the system a bit prettier.

As in: I can't be bothered to write memory safe code.

This project is a great example of where and when Rust should be used.

"sneak" some rust in the kernel? It is exactly this kind of attitude that is slowing progress.