[HN Gopher] DRM Panic QR code generator
___________________________________________________________________
DRM Panic QR code generator
Author : weinzierl
Score : 63 points
Date : 2025-07-04 07:47 UTC (15 hours ago)
(HTM) web link (rust-for-linux.com)
(TXT) w3m dump (rust-for-linux.com)
| danhor wrote:
| It seems like this is already deployed in Arch, as I've hit it
| yesterday. I was surprised at first, but it was quite useful.
| homebrewer wrote:
| It's easy to check (unless the kernel was compiled without
| config in procfs, which it probably wasn't): $
| zgrep CONFIG_DRM_PANIC_SCREEN_QR_CODE /proc/config.gz
| CONFIG_DRM_PANIC_SCREEN_QR_CODE=y
| greatgib wrote:
| Fun, and nice addition, but again another good example of let's
| sneak some rust in critical parts of the kernel so that rust will
| become mandatory.
|
| I would not really have noticed if there wasn't this section
| about why rust, where arguments looks phony and clearly made up
| afterward to justify a decision that was already taken:
| This project was written in rust, because memory safety is
| critical in a panic handler. For this particular
| case, I found the Rust code to be cleaner, and easier to read.
| rcxdude wrote:
| I suspect it's more of a 'this would be handy to have, and I
| would prefer to use rust' as opposed to motivated by making the
| language harder to do without in the kernel. Certainly this
| kind of thing I would find rust much nicer for than C.
|
| (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)
| tialaramex wrote:
| The elaborate Rust type system and so on does not exist in
| the machine code executing when "the system is already
| crashing". Very often it turns out that expressive Rust you
| wrote which talks about a fancy Iterator protocol and a
| lambda function just got compiled into the same sixteen CPU
| instructions that would have been emitted for the (much
| harder to understand) macro expanded C you'd have to write
| instead with the same meaning.
|
| Rust vs C matters a lot more for maintainers, who read the
| source code - hopefully not from a machine which is currently
| crashing - than for the executable kernel itself.
| rcxdude wrote:
| I'm aware, whuch means that e.g. you're liekly already in
| undefined behaviour land and rust's safety guarantees are
| no longer, well, guaranteed.
| jeroenhd wrote:
| The first version of the PR is a little more honest:
| https://patchwork.freedesktop.org/series/135886/
|
| > 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.
| meindnoch wrote:
| >Good on her for trying
|
| "Pronouns: He/Him" https://gitlab.com/kdj0c
| jeroenhd wrote:
| Good catch, didn't spot that on the freedesktop site and
| the docs page linked. I've edited my comment.
|
| My apologies to kdj0c if he's reading this.
| greatgib wrote:
| > > 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.
|
| Good catch the earlier comment, with that I would not even
| have raise an eyebrow because it is more a motivation that I
| find valid and not fishy like the post rationalization that
| is in the original post.
|
| That being said, I still find it ridicule the attempt to
| emphasis on how dangerous it is to do "C code" for the kernel
| because not memory safe all of that, when you see for how
| long the kernel exist, was able thrive, with relatively few
| critical issues in the end compared to most software out
| there.
| ChocolateGod wrote:
| What's the need for memory safety if the kernel is going to
| stop executing and memory will be wiped before any further
| execution is done.
| krior wrote:
| Memory safety is not just about releasing unused memory.
| kookamamie wrote:
| Agreed, picking Rust for the project likely has very little to
| do with "memory safety".
| varispeed wrote:
| > because memory safety is critical in a panic handler.
|
| As in: I can't be bothered to write memory safe code.
| rs186 wrote:
| > let's sneak some rust in critical parts of the kernel so that
| rust will become mandatory.
|
| 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.
| justsomehnguy wrote:
| IMO "sneaking" in some important yet not critical parts is
| the way to both test the tech and how it plays along
| josephcsible wrote:
| Rust being mandatory in Linux will be a good thing. I eagerly
| await the day that (aside from arch-specific syscall boundary
| code, etc. that has to be assembly) the entire kernel becomes
| 100% Rust only.
| dmitrygr wrote:
| Absolutely nobody stops you from writing one in rust. Have
| fun.
| josephcsible wrote:
| I'm not saying that it's easy or that I could do it. I'm
| just saying that if it does happen, it would be a good
| thing, not something you should be opposed to.
| Am4TIfIsER0ppos wrote:
| How am I supposed to use a QR code when the only thing that I
| have to decode it is currently panicking? If I am supposed to
| draw it I hope it is only a few bits. A traditional BSOD with
| codes and registers would be easier to copy.
| bauruine wrote:
| It may isn't useful for you but a huge majority has a phone
| they can use for this task.
| elmigranto wrote:
| What if your phone's kernel panics? :)
| tialaramex wrote:
| Did you know other people have phones too?
| ChocolateGod wrote:
| That's planned obsolescence and you should get a new one.
| andrelaszlo wrote:
| Bring out the crayons and some graph paper!
| preisschild wrote:
| Get your second phone, duh :)
| weinzierl wrote:
| In this context DRM stands for _Direct Rendering Manager_.
|
| It has nothing to do with digital rights management.
| userbinator wrote:
| Do not want. More dumbing down and opaqueing? This is as stupid
| as what happened to Windows' BSoDs.
| preisschild wrote:
| Have you even read what it does in the link? How is it "dumbing
| down and opaqueing" to just encode the kernel panic in a QR
| code?
|
| Its not like in windows where you get some cryptic error code.
| This is just encoding kernel panic traces as a QR code, so more
| can fit on the screen without scrolling and copying is easy.
___________________________________________________________________
(page generated 2025-07-04 23:01 UTC)