Torvalds blasts tardy kernel dev: Your 'garbage' RISC-V patches are 'making the world worse'
- Reference: 1754909115
- News link: https://www.theregister.co.uk/2025/08/11/torvalds_blasts_tardy_kernel_dev/
- Source link:
Torvalds' brusque attitude was perhaps most well demonstrated in a [1]2012 interview in which harsh yet arguably deserved invective was thrust, alongside a middle finger, at graphics giant turned AI cash-cow Nvidia.
Yet this was relatively mild compared to how he reacted to [2]Intel's Spectre patch . His aggressive responses are known to have [3]chased people out of kernel development , and in 2018 [4]Torvalds issued an apology for "flippant attacks" which "have been both unprofessional and uncalled for."
[5]
The Linux dev-in-chief then took a break from active development of the kernel and came back with a desire to be a little more mellow. However, it seems that he can still be provoked. In this instance, it was Google staffer Palmer Dabbelt, a long-time contributor, who suffered Torvalds' ire, having submitted a range of patches for RISC-V support in Linux 6.17.
[6]
[7]
"This is very late," Dabbelt admitted in the post to the Linux kernel mailing list (LKML), "so I don't plan on having a part 2 unless something goes off the rails. There's a few trivial merge conflicts with the SBI drivers, just from having multiple drivers flight. Maybe it'd be better to have these drivers in other trees, but the SBI stuff is pretty tied to RISC-V and they seemed stuck. Aside from that thinks [sic] look clean on my end."
Torvalds came to a very different conclusion – though he agreed fully with Dabbelt that the patch set was submitted far too late into the merge window, just one day before it closes, to be included.
[8]
"No," he wrote in response. "This is garbage and it came in too late. I asked for early pull requests because I'm travelling, and if you can't follow that rule, at least make the pull requests *good*.
"This adds various garbage that isn't RISC-V specific to generic header files. And by 'garbage' I really mean it. This is stuff that nobody should ever send me, never mind late in a merge window. Like this crazy and pointless make_u32_from_two_u16() 'helper'. That thing makes the world actively a worse place to live. It's useless garbage that makes any user incomprehensible, and actively *WORSE* than not using that stupid 'helper'."
Torvalds' primary complaint goes beyond the lateness of the patches and extends to the quality of the code itself. The key, but not only, issue: a helper function for converting two unsigned 16-bit integers to a 32-bit integer that is overly complicated and means anyone calling it has "not a f%^5ing [sic] clue what the word order is" - and which lives outside the RISC-V code base.
[9]
"IOW, you just made things *WORSE*, and you added that 'helper' to a generic non-RISC-V file where people are apparently supposed to use it to make *other* code worse too," Torvalds continued in, admittedly, a more restrained rant than would perhaps have been the case prior to his reformation.
[10]'Maybe the problem is you' ... Linus Torvalds wades into Linux kernel Rust driver drama
[11]Torvalds' typing taste test touches tactile tragedy
[12]Linus Torvalds offers to build guitar effects pedal for kernel developer
[13]Linus Torvalds: 90% of AI marketing is hype
[14]Combustion engines grind Linus Torvalds' gears
"So no. Things like this need to get bent. It does not go into generic header files, and it damn well does not happen late in the merge window. You're on notice: no more late pull requests, and no more garbage outside the RISC-V tree."
Dabbelt, for his part, seemed to accept his lumps. "OK, sorry," he replied. "I've been dropping the ball lately and it kind of piled up as taking a bunch of stuff late, but that just leads to me making mistakes. So I'll stop being late, and hopefully that helps with the quality issues."
The full thread is available on the [15]LKML archive .
Any RISC-V fans eager for the fixes and features the patch set was supposed to deliver will have to wait until Linux 6.18 at the least, providing, Torvalds warns, that the set is submitted "EARLY in that merge window [...] and without the garbage."
Ouch. ®
Get our [16]Tech Resources
[1] https://www.theregister.com/2012/06/18/torvalds_curses_nvidia/
[2] https://www.theregister.com/2018/01/22/intel_spectre_fix_linux/
[3] https://www.theregister.com/2015/10/06/linix_kernel_dev_who_asked_linus_torvalds_to_stop_swearing_quits_over_swearing/
[4] https://www.theregister.com/2018/09/17/linus_torvalds_linux_apology_break/
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aJoTmD419fmMafz2_HNO0QAAAAs&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aJoTmD419fmMafz2_HNO0QAAAAs&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aJoTmD419fmMafz2_HNO0QAAAAs&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aJoTmD419fmMafz2_HNO0QAAAAs&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aJoTmD419fmMafz2_HNO0QAAAAs&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[10] https://www.theregister.com/2025/02/07/linus_torvalds_rust_driver/
[11] https://www.theregister.com/2025/05/20/torvalds_typing_taste_test_touches/
[12] https://www.theregister.com/2025/01/13/linus_torvalds_guitar_pedal_offer/
[13] https://www.theregister.com/2024/10/29/linus_torvalds_ai_hype/
[14] https://www.theregister.com/2024/10/30/linus_torvalds_ev/
[15] https://lore.kernel.org/lkml/mhng-7755CB81-B0C6-42D3-82B5-CE37669F176C@palmerdabbelt-mac/
[16] https://whitepapers.theregister.com/
Re: Dislike the delivery
Meh. If you don't make things painfully clear to some people, they won't even understand what the problem is.
Linus is not a bad person because he doesn't suffer fools gladly. Contributors to the Linux kernel should be professional and mindful of the standards which are expected. It's not a touchy-feely education course.
To be honest, I thought his reply was quite polite and measured.
Re: Dislike the delivery
I once said a whole lot worse to a supportably experienced software engineer who tried to deliver some over-complicated and totally uncommented code that would only run without crashing on the very limited test cases they used to "prove that it conforms to specification". I was, however, restrained - I delivered my opinion in a private office with the door closed, and not in the open-plan office space in which I first saw the code submission.
Re: Dislike the delivery
'the very limited test cases they used to "prove that it conforms to specification"'
If it was supposed to do more than "conform to specification" as it was, then I hope you gave the specification writers a bollocking too for incomplete specifications.
Insufficient documentation is a pain, sure, have a whinge about that, but you can't berate them for testing to specification.
Re: Dislike the delivery
The way that sorted of thing normally happens is you write a good spec, then the developer picks a small number of test cases and writes code to those tests, not to the specification.
The programmer wrongly claims it confirms to the spec because it passes their tests.
That's not a spec issue, it's a programmer issue.
Re: Dislike the delivery
When I was doing commercial work, the way things normally happened was that the developer and tester had copies of the unit interface spec, and wrote the code and test cases separately.
Re: Dislike the delivery
Ideally in a way that the developer can point out the errors in the testing when the code fails tests (I've had this a number of times, where I knew my code worked as it passed the tests I ran before handing it over to the test team).
Re: Dislike the delivery
> I was, however, restrained - I delivered my opinion in a private office with the door closed, and not in the open-plan office space in which I first saw the code submission.
Thing is, the code that goes into the Linux kernel, ends up on tens of billions of devices, from supercomputers all the way down to smart fridges. That's why these discussions are in the open, NEED to be open, on a mailing-list, and not behind closed doors. The world depends on Linux, and by extension, on Kernel hackers to not drop the ball.
The people writing that code literally make the software that keeps civilisation spinning.
Re: Dislike the delivery
If you don't make things painfully clear to some people ...
That is (unfortunately) so.
Linux does not run like it runs just because .
I does so because the Torvalds is on top of things.
And even then, has to deal with the type of BS that brought this to light.
It's been said here more than once:
Linus is the one signing off on whatever is sent to him.
It is his project, his reputation and finally, his name.
.
Linus is not a bad person because he doesn't suffer fools gladly.
He's obviously a bad person because he lets systemd live.
Re: Linus is not a bad person because he doesn't suffer fools gladly.
Linus manages the Linux kernel development.
systemd has absolutely nothing to do with the linux kernel, its's a PID 1 init procss. The kernel couldn't care less what process it starts as PID 1, nor does it have to.
Re: Dislike the delivery
> If you don't make things painfully clear to some people, they won't even understand what the problem is.
You can keep telling yourself that to justify your approach.
Some developers do have to shape up or ship out. But making them hate you is never the correct resolution.
There is a world of difference between “this is garbage code” and “you’re a garbage coder.” One is defensible - the other is not. New Linus seems to be staying very much on the correct side of that line.
I agree with Linus
The function helper seems a bit pointless.
And that response seemed quite restrained tbh
I saw this elsewhere ...
I had to say his point about the potentially misleading and dangerous helper function contaminating a generic header is the kind of quality control that has kept the Linux kernel from descending to chaos.
Compared with some of the absolutely unacceptable behaviour that developers and their management I have observed, I would have to say Linus here would be the paradigm of civility.
Re: I saw this elsewhere ...
"Compared with some of the absolutely unacceptable behaviour that developers and their management I have observed, I would have to say Linus here would be the paradigm of civility."
Agree, openssl when it was back in the nonsense 4 numbers + one letter numbering schema still, just after heardbleed is one example.
Now, I've had a look recently and a massive part seems to have been re-written in real C and not any longer the Chthulu C style language !
Linus or one of “Jia Tan” sock puppet accounts? What are the rules when engaging with developers?
Be advised.
I often use a hobbyist board that is run by someone with an aspie lack of empathy in social interactions. Any minor fault and you get a massive public bollocking.
It's a useful board, but lots of people who could post on it simply don't. Nobody likes being yelled at,
So, carry on like that, and folk will just avoid the aggro by not being part of it.
There is more to good management than being right.
Dislike the delivery
The delivery is terrible, he is a bad person, really. But he is quite right.