The Unix signal interface is complex and hard to work with; some developers have argued that its design is "unfixable". So when Walt Drummond proposed increasing the number of signals that Linux systems could manage, eyebrows could be observed at increased altitude across the Internet. The proposed increase seems unlikely to happen, but the underlying goal — to support a decades-old feature from other operating systems — may yet become a reality.

The kernel is able to support up to 64 different signal types, which seems like a fair number, but all 64 are taken, on some architectures at least. That makes it impossible to add new signal types to Linux. Drummond sought to address that problem by raising the limit to 1024, which would surely be enough for all time. Raising the limit requires making some subtle changes to the user-space API (putting a larger signal mask into the information passed to realtime signal handlers, for example) that have the possibility of breaking applications, which means that extra scrutiny would be required. But that, it seems, is what would be needed to be able to add more signals.

Linux supports processor architectures where CPUs in the same system might have different processing capacities; for example, the Arm big.LITTLE systems combine fast, power-hungry CPUs with slower, more efficient ones. Linux has also run for years on simultaneous multithreading (SMT) architectures, where one CPU executes multiple independent execution threads and is seen as if it were multiple cores. There are architectures that mix both approaches. A recent discussion on a patch set submitted by Ricardo Neri shows that, on these systems, the scheduler might distribute tasks in an inefficient way.

The 5.16 kernel was released on January 9, as expected. This development cycle incorporated 14,190 changesets from 1,988 developers; it was thus quite a bit busier than its predecessor, and fairly typical for recent kernel releases in general. A new release means that the time has come to have a look at where those changes came from.

The 1,998 developers contributing to 5.16 was the second-highest number ever, with only 5.13 (with 2,062 developers) being higher. This time around, 296 developers contributed their first change to the kernel, which is at the high end of the typical range.

F2FS as the Flash-Friendly File-System may not see too much use out of desktop Linux distributions at least as it concerns any easy/semi-endorsed root install option, but this file-system does continue maturing and seeing much use by enthusiasts and especially among the plethora of Android devices now supporting this flash-optimized file-system. With Linux 5.17, F2FS has some performance improvements and other fixes.

F2FS lead developer and maintainer Jaegeuk Kim sent in the Flash-Friendly File-System updates on Tuesday. This cycle there is work for addressing performance issues in the checkpoint and direct I/O code. There is also improvements to the page cache management code used as part of the file-system compression support.