X
Business

Linus Torvalds releases Linux 5.3: Kernel fixes are about user impact, nothing else

Linux kernel developers get a gentle reminder of a lesson Linus Torvalds has been shouting at them for years: if there's no user impact, shut up.
Written by Liam Tung, Contributing Writer

Linux kernel boss Linus Torvalds has finally announced the release of Linux 5.3, after eight release candidates and a delay of one week.

But that delay has been a good thing, according to Torvalds, because it gives kernel developers an important lesson in what's important and how to frame issues when reporting bugs.  

Torvalds had a busy schedule last week, speaking with ZDNet's open-source authority, Steven J Vaughan-Nichols, at not one but two core Linux conferences – the Kernel Maintainers Summit and the Linux Plumbers Conference, held in Lisbon, Portugal last week.

SEE: How to build a successful developer career (free PDF)

There, kernel developers hashed out glitches in the "process of creating and maintaining the Linux kernel" in teams from around the globe, across large organizations including Google, IBM, Intel, and Nvidia. 

Process, it seems, was on Torvalds' mind when announcing Linux 5.3 on Sunday. The delay to the new release wasn't all bad news because it allowed for some "good fixes" to come in, particularly one issue that wasn't in itself a bug but which illustrated the difficulties the project has with process and communication. 

"One particularly last-minute revert is the top-most commit (ignoring the version change itself) done just before the release, and while it's very annoying, it's perhaps also instructive," wrote Torvalds

As he explains, the commit itself wasn't buggy at all, but it did its job so well that "much improved IO patterns it caused then ended up revealing a user-visible regression due to a real bug in a completely unrelated area" that would have messed up a kernel upgrade. 

"The actual details of that regression are not the reason I point that revert out as instructive, though. It's more that it's an instructive example of what counts as a regression, and what the whole 'no regressions' kernel rule means," wrote Torvalds. 

"The reverted commit didn't change any APIs, and it didn't introduce any new bugs. But it ended up exposing another problem, and as such caused a kernel upgrade to fail for a user. So it got reverted."

The point he was making is that the decision to revert a change was made because it was framed in a way that clearly impacted the user, rather than some esoteric explanation of a problem that doesn't capture how people's work is impacted.  

"Take-away from the whole thing: it's not about whether you change the kernel-userspace ABI, or fix a bug, or about whether the old code 'should never have worked in the first place'. It's about whether something breaks existing users' workflow."

The Linux boss then gave a nod to one of his most controversial emails to all Linux developers, in which he told one contributor to "SHUT THE FUCK UP!" in 2012.  

"Anyway, that was my little aside on the whole regression thing. Since it's that 'first rule of kernel programming', I felt it is perhaps worth just bringing it up every once in a while," wrote Torvalds on Sunday. 

SEE: Linus Torvalds: People take me much too seriously, I can't say stupid crap anymore

It was a reference to emails he'd sent to developers before he took a break last year from leading the project and vowed to take a less offensive approach to communicating with kernel developers.  

Back in 2012, he told one developer: "It's a bug alright – in the kernel. How long have you been a maintainer? And you *still* haven't learnt the first rule of kernel maintenance? If a change results in user programs breaking, it's a bug in the kernel. We never EVER blame the user programs. How hard can this be to understand?"

The update includes a host of fixes for AMD and Intel graphics drivers, including better support for Radeon RX 5700 Navi, Intel Icelake Gen 11 graphics, and early Intel HDR display support.   

More on Linux and Linus Torvalds

Editorial standards