steven36 Posted September 16, 2019 Share Posted September 16, 2019 Linus Torvalds has just announced the release of Linux 5.3: So we’ve had a fairly quiet last week, but I think it was good that we ended up having that extra week and the final rc8. Even if the reason for that extra week was my travel schedule rather than any pending issues, we ended up having a few good fixes come in, including some for some bad btrfs behavior. Yeah, there’s some unnecessary noise in there too (like the speling fixes), but we also had several last-minute reverts for things that caused issues. 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. What’s instructive about it is that I reverted a commit that wasn’t actually buggy. In fact, it was doing exactly what it set out to do, and did it very well. In fact it did it _so_ well that the much improved IO patterns it caused then ended up revealing a user-visible regression due to a real bug in a completely unrelated area. 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. The reverted commit didn’t change any API’s, 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 here being that we revert based on user-reported _behavior_, not based on some “it changes the ABI” or “it caused a bug” concept. The problem was really pre-existing, and it just didn’t happen to trigger before. The better IO patterns introduced by the change just happened to expose an old bug, and people had grown to depend on the previously benign behavior of that old issue. And never fear, we’ll re-introduce the fix that improved on the IO patterns once we’ve decided just how to handle the fact that we had a bad interaction with an interface that people had then just happened to rely on incidental behavior for before. It’s just that we’ll have to hash through how to do that (there are no less than three different patches by three different developers being discussed, and there might be more coming…). In the meantime, I reverted the thing that exposed the problem to users for this release, even if I hope it will be re-introduced (perhaps even backported as a stable patch) once we have consensus about the issue it exposed. 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. 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. Other than that aside, I don’t find a lot to really talk about last week. Drivers, networking (and network drivers), arch updates, selftests. And a few random fixes in various other corners. The appended shortlog is not overly long, and gives a flavor for the changes. And this obviously means that the merge window for 5.4 is open, and I’ll start doing pull requests for that tomorrow. I already have a number of them in my inbox, and I appreciate all the people who got that over and done with early, Linus Linux 5.2 added sound open firmware for audio DSPs, a new mount API for more complex scenarios, performance improvement for BFQ I/O scheduler, Lima and Panfrost open-source drivers for some Arm GPUs, and more. Some notable changes in Linux 5.3 include: Support for AMD Navi GPUs – AMD RX5700 GPUs added in amdgpu drivers with support for the core driver, displays (DCN2), GFX and compute (GFX10), System DMA (SDMA 5), Multimedia decode and encode (VCN2) and Power management. Support for Zhaoxin x86 CPUs – The architecture of the ZX family of processors is a continuation of VIA’s Centaur Technology x86-64 Isaiah design. Intel Speed Select support – Power management technology that lets users configure their servers for throughput and per-core performance settings, allowing the prioritization of performance for certain workloads running on specific cores by sacrificing the performance of other cores. Works on some Xeon processors only 16 million new IPv4 addresses – The 0.0.0.0/8 IPv4 range will be accepted by Linux (despite not being declared as such in standards) as a valid address range, allowing for 16 million new IPv4 addresses. See IPv4 cleanup project for more details. IoT ACRN supervisor added – The ACRN hypervisor is a flexible, lightweight reference hypervisor, built with real-time and safety-criticality in mind, optimized for resource-constrained embedded systems. For a full list of changes, you could check out the complete Linux 5.3 changelog with comments generated using git log v5.2..v5.3-rc8 --statcommand. You may also want to visit Kernelnewbies website for another take on the changelog. Source Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.