Language Selection

English French German Italian Portuguese Spanish

Latest LWN Articles About Linux (Paywall Has Just Expired)

Filed under
  • SPDX identifiers in the kernel

    Observers of the kernel's commit stream or mailing lists will have seen a certain amount of traffic referring to the addition of SPDX license identifiers to kernel source files. For many, this may be their first encounter with SPDX. But the SPDX effort has been going on for some years; this article describes SPDX, along with why and how the kernel community intends to use it.

    On its face, compliance with licenses like the GPL seems like a straightforward task. But it quickly becomes complicated for a company that is shipping a wide range of software, in various versions, in a whole set of different products. Compliance problems often come about not because a given company wants to flout a license, but instead because that company has lost track of which licenses it needs to comply with and for which versions of which software. SPDX has its roots in an effort that began in 2009 to help companies get a handle on what their compliance obligations actually are.

    It can be surprisingly hard to determine which licenses apply to a given repository full of software. The kernel's COPYING file states that it can be distributed under the terms of version 2 of the GNU General Public License. But many of the source files within the kernel tell a different story; some are BSD licensed, and many are dual-licensed. Some carry an exception to make it clear that user-space programs are not a derived product of the kernel. Occasionally, files with GPL-incompatible licenses have been found (and fixed).

  • 4.15 Merge window part 1

    When he released 4.14, Linus Torvalds warned that the 4.15 merge window might be shorter than usual due to the US Thanksgiving holiday. Subsystem maintainers would appear to have heard him; as of this writing, over 8,800 non-merge changesets have been pulled into the mainline since the opening of the 4.15 merge window. Read on for a summary of the most interesting changes found in that first set of patches.

  • 4.15 Merge window part 2

    Despite the warnings that the 4.15 merge window could be either longer or shorter than usual, the 4.15-rc1 prepatch came out right on schedule on November 26. Anybody who was expecting a quiet development cycle this time around is in for a surprise, though; 12,599 non-merge changesets were pulled into the mainline during the 4.15 merge window, 1,000 more than were seen in the 4.14 merge window. The first 8,800 of those changes were covered in this summary; what follows is a look at what came after.

  • BPF-based error injection for the kernel

    Diligent developers do their best to anticipate things that can go wrong and write appropriate error-handling code. Unfortunately, error-handling code is especially hard to test and, as a result, often goes untested; the code meant to deal with errors, in other words, is likely to contain errors itself. One way of finding those bugs is to inject errors into a running system and watching how it responds; the kernel may soon have a new mechanism for doing this sort of injection.

    As an example of error handling in the kernel, consider memory allocations. There are few tasks that can be performed in kernel space without allocating memory to work with. Memory allocation operations can fail (in theory, at least), so any code that contains a call to a function like kmalloc() must check the returned pointer and do the right thing if the requested memory was not actually allocated. But kmalloc() almost never fails in a running kernel, so testing the failure-handling paths is hard. It is probably fair to say that a large percentage of allocation-failure paths in the kernel have never been executed; some of those are certainly wrong.

  • Tools for porting drivers

    Out-of-tree drivers are a maintenance headache, since customers may want to use them in newer kernels. But even those drivers that get merged into the mainline may need to be backported at times. Coccinelle developer Julia Lawall introduced the audience at Open Source Summit Europe to some new tools that can help make both forward-porting and backporting drivers easier.

    She opened her talk by noting that she was presenting step one in her plans, she hoped to be able to report on step two next year some time. The problem she is trying to address is that the Linux kernel keeps moving on. A vendor might create a driver for the 4.4 kernel but, over the next six months, the kernel will have moved ahead by another two versions. There are lots of changes with each new kernel, including API changes that require driver changes to keep up.

    That means that vendors need to continually do maintenance on their drivers unless they get them upstream, where they will get forward-ported by the community. But the reverse problem is there as well: once a device becomes popular, customers may start asking for it to run with older kernels too. That means backporting.

More in Tux Machines

A Look At The Windows vs. Linux Scaling Performance Up To 64 Threads With The AMD 2990WX

This past week we looked at the Windows 10 vs. Linux performance for AMD's just-launched Ryzen Threadripper 2990WX and given the interest from that then ran some Windows Server benchmarks to see if the performance of this 64-thread CPU would be more competitive to Linux. From those Windows vs. Linux tests there has been much speculation that the performance disparity is due to Windows scheduler being less optimized for high core/thread count processors and its NUMA awareness being less vetted than the Linux kernel. For getting a better idea, here are benchmarks of Windows Server 2019 preview versus Ubuntu Linux when testing varying thread/core counts for the AMD Threadripper 2990WX. Toggled via the BIOS was SMT as well as various CCX configurations and each step of the way comparing the Windows Server 2019 Build 17733 performance to that of Ubuntu 18.04 LTS with the Linux 4.18 kernel in various multi-threaded benchmarks supported under both operating systems. Read more

Kernel: RISC-V and Virtual Machine

  • RISC-V's Linux Kernel Support Is Getting Into Good Shape, Userspace Starting To Work
    The RISC-V open-source processor ISA support within the mainline kernel is getting into good shape, just a few releases after this new architecture port was originally added to the Linux Git tree. The RISC-V code for Linux 4.19 includes the ISA-mandated timers and first-level interrupt controllers, which are needed to actually get user-space up and running. Besides the RISC-V first-level interrupt controller, Linux 4.19 also adds support for SiFive's platform-level interrupt controller that interfaces with the actual devices.
  • A Hearty Batch Of KVM Updates Land In Linux 4.19
    There is a lot of new feature work for the Kernel-based Virtual Machine (KVM) within the Linux 4.19 kernel.

Kate/KTextEditor Picks Up Many Improvements To Enhance KDE Text Editing

Even with KDE's annual Akademy conference happening this past week in Vienna, KDE development has been going strong especially on the usability front. The Kate text editor and the KTextEditor component within KDE Frameworks 5 have been the largest benefactors of recent improvements. This KDE text editing code now has support for disabling syntax highlighting entirely if preferred. When using syntax highlighting, there have been many KTextEditor enhancements to improve the experience as well as improvements to the highlighting for a variety of languages from JavaScript to YAML to AppArmor files. Read more

KStars v2.9.8 released

KStars 2.9.8 is released for Windows, MacOS, and Linux. It is a hotfix release that contains bug fixes and stability improvements over the last release. Read more Also: KDE Itinerary - How did we get here?