The developments in this edition share one practical theme: the Linux base is being reshaped to reduce long-term maintenance cost. A new scheduler feature helps the kernel use modern multi-cache processors better, a major silicon vendor is moving its embedded BSP to an upstream-first model, an old special-purpose ABI is being retired, and a new Yocto LTS sets the build base teams will standardise on for years, with security defaults aimed at coming regulation. None of these is a dramatic feature launch. Together they change how much work teams will spend keeping products supportable over the next several years.
In this edition
- Cache-aware scheduling merged for Linux 7.2. A new opt-in scheduler option, CONFIG_SCHED_CACHE, keeps cooperating tasks on CPUs that share a last-level cache, which matters for modern multi-cache processors. (Phoronix)
- Qualcomm announces an upstream-first Linux 2.0 for Dragonwing IoT. Qualcomm is replacing its fragmented, per-platform BSPs with a unified BSP that tracks mainline, with a public demonstration scheduled for 30 June. (CNX Software)
- Kernel developers propose removing the x32 ABI. A patch sets a timeline to retire the rarely used x32 ABI, supported since Linux 3.4 in 2012, after the summer if no objections are raised. (LWN.net)
- Yocto Project 6.0 “Wrynose” ships as an LTS. The new Yocto LTS pairs Linux 6.18 LTS with four years of support and security defaults aimed at the EU Cyber Resilience Act, including a new sbom-cve-check tool. (CNX Software)
Cache-aware scheduling lands in the Linux 7.2 merge window
The Linux 7.2 merge window opened on 14 June, immediately after Linus Torvalds released Linux 7.1, and the scheduler pull request for 7.2 includes cache-aware scheduling, exposed through a new Kconfig option named CONFIG_SCHED_CACHE (Phoronix). The feature was developed over more than a year of public patch review under scheduler maintainer Peter Zijlstra. Its purpose is straightforward: when several tasks share data, the scheduler tries to place them on CPUs that belong to the same last-level cache (LLC) domain, so the data stays in a shared cache instead of being moved between caches on different parts of the chip.
This matters because processor cache layouts have become more complex. Server parts such as AMD EPYC and Intel Xeon now contain several separate last-level caches across chiplets or clusters. Embedded SoCs are following the same direction, with multiple CPU clusters that do not all share one cache. On such hardware, two threads that exchange data can lose performance if the scheduler keeps moving them between clusters. Cache-aware scheduling addresses that case directly. Reported benchmarks on earlier versions showed gains on AMD EPYC and Intel Xeon 6 systems.
For most embedded teams, a measured response fits best. The option is off by default, so upgrading to 7.2 does not change behaviour unless CONFIG_SCHED_CACHE is enabled. Treat it as a tuning option for workloads with several cooperating threads on multi-cluster SoCs, and measure before and after on your own hardware rather than assuming a benefit. Single-cluster parts with one shared cache will see little or no change. This is also a useful teaching example of how scheduler placement affects real throughput, and it is the kind of topic we work through in our kernel internals training at TECH VEDA, because understanding cache topology is now part of performance work, not an optional extra.
Qualcomm moves Dragonwing to an upstream-first BSP with Linux 2.0
Qualcomm has announced Qualcomm Linux 2.0 for its Dragonwing IoT platforms, described as a reset rather than an incremental update (CNX Software). The central change is an upstream-first model with a board support package that tracks the mainline kernel, together with a unified BSP across Dragonwing platforms, a single system image, and an overlay-based architecture intended to keep customisations separate and maintainable. A public demonstration covering the lifecycle, release strategy, Yocto changes, and migration paths is scheduled for 30 June. Early documentation already covers the Dragonwing RB3 Gen 2 kits and parts such as IQ-9075, IQ-8275, and IQ-615.
Anyone who has maintained a vendor BSP understands the problem this targets. Traditional embedded BSPs are often kernel forks pinned to an old version, carrying large out-of-tree patch sets. Each security fix or feature backport then becomes manual work, and moving to a newer kernel can require a full bring-up again. An upstream-first BSP that tracks mainline, with customisations kept as overlays rather than in-tree edits, reduces that recurring cost and makes kernel upgrades more predictable.
This is a positive direction, but it should be judged on delivery rather than on the announcement. The questions worth asking are concrete: how close to mainline the tracking kernel actually stays, how long each release is supported, how clean the overlay separation is in practice, and how much effort migration from earlier Qualcomm Linux releases requires. Teams selecting a Dragonwing platform for a new product should review the 30 June material and the migration guidance before committing, and check the upstream-first claims against the actual patch delta in the shipped BSP.
The x32 ABI is proposed for removal
Kernel developer Sebastian Andrzej Siewior has submitted a patch proposing the gradual removal of the x32 ABI, with a timeline that would remove the code after the summer, around August 2026, if no objections are raised within six months (LWN.net). The x32 ABI has been supported since Linux 3.4 in 2012. It was designed to combine the extra registers of x86-64 with 32-bit pointers to reduce memory use, but it never reached wide adoption. So far the proposal has met no objections, only a request not to reuse its system call numbers in future. Removing x32 would also free around 40 system call numbers for regular x86-64 use.
For most embedded teams this carries no impact, because x32 is an x86-64 feature and was never common in embedded deployments. The one thing worth checking is whether any part of your build configuration enables x32 out of habit. Some distributions still carry small x32 ports; Gentoo, Debian, and PLD Linux were noted as still having users. On an x86-64 target with CONFIG_X86_X32_ABI set, confirm that nothing in your userspace actually depends on it, then plan to drop it. This is routine reduction of legacy code, and it lowers the kernel’s long-term test and maintenance surface, which is a benefit even for teams that never used the feature.
Yocto Project 6.0 “Wrynose” arrives as the new LTS
The Yocto Project has released version 6.0, codenamed “Wrynose”, built on the Linux 6.18 LTS kernel and carrying long-term support until at least April 2030 (CNX Software). It is the first LTS since 5.0 “Scarthgap” roughly two years ago, with more than 4,000 commits from over 240 contributors since the 5.3 “Whinlatter” interim release. The toolchain moves to GCC 15.2, glibc 2.43, LLVM 22.1, Go 1.26, and Rust 1.94. New tooling includes bitbake-setup for fetching layers and preparing build directories, and BitBake configuration fragments managed through bitbake-config-build for reusable build configuration.
The changes that matter most for product teams are about security and compliance. Wrynose improves SBOM and CVE handling, replaces the older cve-check bbclass with a new sbom-cve-check tool, extends SPDX 3.0 output with initial PURL and concluded-license support, and disables TLS 1.0 and 1.1 by default in OpenSSL. The stated goal is to make it easier to meet the EU Cyber Resilience Act, which is becoming a real obligation for products sold into the European market. Two defaults also change behaviour: systemd is now the default init system for nodistro builds and for distributions not derived from Poky, while Poky itself stays on sysvinit, and the documented host requirements have risen to 32GB of RAM and 140GB of disk, driven mainly by LLVM compilation.
For teams on a 5.x release, Wrynose is the migration target to schedule now rather than near a deadline, because the four-year support window and the CRA-oriented defaults reduce both maintenance and compliance work over the product lifetime. A few items deserve attention during the move. Any recipe or CI step that called the old cve-check class needs updating to sbom-cve-check. The systemd default change can surprise non-Poky distributions, so confirm the init system explicitly in your distro configuration rather than relying on the inherited value. The higher host requirements affect build-server and CI sizing, so budget for them before the migration rather than discovering them mid-build. The official migration guide for 5.x users is the right starting point. Working through a Yocto migration of this kind, including the SBOM and CVE workflow, is also part of what we cover in embedded Linux training at TECH VEDA.
References
- Phoronix — Cache Aware Scheduling Merged For Linux 7.2
- LWN.net — The rest of the 7.1 merge window
- CNX Software — Qualcomm Linux 2.0 upstream-first for Dragonwing IoT
- LWN.net — Reconsidering x32 — again
- Phoronix — Linux Developers Looking At Retiring The x32 ABI
- CNX Software — Yocto Project 6.0 “Wrynose” released with Linux 6.18 LTS
- Yocto Project — Migration guide to 6.0
— Raghu Bharadwaj
