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.
> 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.
> > 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.
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)
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.
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.
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.
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.
It's always easier to read and share text, e.g. over the phone, and not have to rely on another complex layer of obscurity --- especially when you're trying to figure out what happened.
I think a QR code is easier for most people to share in a computer-readable format. You take a picture on your phone and either decode the QR code on your phone or send the picture to another computer and decode it there. The alternative is taking a picture on your phone of a screen of text, and either manually typing out what it says or using OCR, which (given pictures I've seen where people take pictures of their screen) is going to run into difficulties
That is even assuming that the TTY has the correct resolution for your monitor, that is not always the case. If not, it is highly likely that the most important information will be missing, it happened for me quite a few times.
Of course, it doesn't mean that the QR code could also not be cut off the screen, but since QR code is more dense in information (like the post says), I think this is more rare.
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.
In this context DRM stands for Direct Rendering Manager.
It has nothing to do with digital rights management.
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.
It's easy to check (unless the kernel was compiled without config in procfs, which it probably wasn't):
Thanks, also seems enabled by default in NixOS.
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:
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.
> > 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.
>Good on her for trying
"Pronouns: He/Him" https://gitlab.com/kdj0c
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.
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)
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.
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.
> 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.
IMO "sneaking" in some important yet not critical parts is the way to both test the tech and how it plays along
Agreed, picking Rust for the project likely has very little to do with "memory safety".
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.
Memory safety is not just about releasing unused memory.
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.
Absolutely nobody stops you from writing one in rust. Have fun.
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.
> because memory safety is critical in a panic handler.
As in: I can't be bothered to write memory safe code.
Do not want. More dumbing down and opaqueing? This is as stupid as what happened to Windows' BSoDs.
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.
and copying is easy
It's always easier to read and share text, e.g. over the phone, and not have to rely on another complex layer of obscurity --- especially when you're trying to figure out what happened.
I think a QR code is easier for most people to share in a computer-readable format. You take a picture on your phone and either decode the QR code on your phone or send the picture to another computer and decode it there. The alternative is taking a picture on your phone of a screen of text, and either manually typing out what it says or using OCR, which (given pictures I've seen where people take pictures of their screen) is going to run into difficulties
That is even assuming that the TTY has the correct resolution for your monitor, that is not always the case. If not, it is highly likely that the most important information will be missing, it happened for me quite a few times.
Of course, it doesn't mean that the QR code could also not be cut off the screen, but since QR code is more dense in information (like the post says), I think this is more rare.
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.
It may isn't useful for you but a huge majority has a phone they can use for this task.
What if your phone’s kernel panics? :)
Bring out the crayons and some graph paper!
Did you know other people have phones too?
That's planned obsolescence and you should get a new one.
Get your second phone, duh :)