Raghu Bharadwaj

Posted on Sep 22 Originally published at techveda.live

Kernel & Embedded News: Android Binder Goes Rust-Only in Linux 7.4

#linux #kernel #embedded #rust

Android's Binder driver is set to lose its C implementation in Linux 7.4, leaving the Rust implementation as the only one — the first time Rust replaces a deployed C driver in the mainline kernel instead of being added beside one. Two large RFCs from Google engineers question old assumptions: io_uring workers that exchange thread identities to avoid worker-thread overhead, and virtual machines that keep executing while the host kernel reboots. Amlogic announced the first Cortex-A320 SoCs for low-power edge AI, and Ubuntu 26.10 completes its move to Rust coreutils.

This edition is about replacement. Two items replace long-lived C code with Rust, one at the kernel level and one in userland; two more propose replacing settled assumptions about what a thread is and what a host reboot means. The fifth brings Armv9 down into a class of silicon that has run Armv8 little cores for a decade.

In this edition

Android Binder drops its C implementation in 7.4. The Rust driver, upstream since 6.18, becomes the only Binder — and Rust becomes a hard build requirement for Android kernels. — planning signal
io_uring may swap thread identities to avoid blocking costs. A 15-patch RFC lets a worker thread take over the submitting thread's identity only when an operation actually blocks. — long-term watch
"Orphaned VMs": guests keep running while the host kernel is offline. A 46-patch RFC extends the Live Update Orchestrator so vCPUs keep executing across a host kexec reboot. — architecture watch
Amlogic announces the first Cortex-A320 SoCs. The A123X and C305X2 pair Arm's smallest Armv9 core with an 8 TOPS Transformer-capable NPU for cameras and battery devices. — hardware watch
Ubuntu 26.10 completes the Rust coreutils transition. cp, mv and rm switch to the Rust implementations, the final three commands to move. — test now

Android Binder drops its C implementation

Carlos Llamas of Google has posted the patch that removes the C implementation of Binder, Android's central inter-process communication driver, from the kernel: 11,470 lines deleted across twenty files. The standard Binder configuration option is rewired to require Rust support, and the module name that vendor build systems reference now points at the Rust driver. Greg Kroah-Hartman has picked the patch up for the char-misc tree, aimed at the 7.4 merge window that opens after 7.3 releases in the second half of October.

The replacement was prepared over several years. The Rust Binder driver began as a demonstration by Wedson Almeida Filho and has since been maintained by Alice Ryhl; it was upstreamed in Linux 6.18, reached full feature parity rather than a convenient subset, and measures equal to or better than the C driver in performance. It has been running on shipping Android hardware for some time. Llamas' stated reason for the removal is that fifteen years of accumulated complexity made the C driver painful to maintain, with new features hard to land without introducing vulnerabilities — a fair description of a driver that is performance-critical, reference-counted, and reachable from untrusted application code.

For the first time, a Rust implementation is replacing a widely deployed C driver in the mainline kernel instead of being added beside one. Every Rust milestone before this was additive: a new driver, an abstraction layer, an optional alternative. Deleting the C path makes Rust a hard build dependency for any kernel that needs Binder — in practice, every Android vendor kernel, and any distribution kernel that supports Android container stacks.

The patch is queued, not merged, and the 7.4 window has not opened; there has been no visible opposition on the list. Binder also had a motivated corporate owner funding its rewrite to parity for years — most subsystems have no equivalent sponsor, so this is a milestone, not yet a pattern.

What it means for Android and embedded teams

Teams building Android on vendor kernels at 6.6 or 6.12 are not affected until their BSP rebases to 7.4 or later, but the direction is now set: a working Rust toolchain in the kernel build becomes as basic as a working C compiler for Android work. Check today whether your kernel CI can build with Rust enabled, and treat the ability to read Rust kernel code as a near-term skill requirement for anyone who debugs IPC on Android systems.

io_uring proposes exchanging thread identities

Jens Axboe, the io_uring maintainer, posted a 15-patch RFC on 11 September with an unusual answer to an old problem. io_uring promises not to block the submitting thread, but several operations — fdatasync, statx, some openat paths — run through kernel code that was never written to be asynchronous. Today, any such operation is handed to a worker thread up front, paying a wakeup and a context switch even when the operation would have completed without blocking at all.

The RFC issues these operations inline instead, and reacts only when blocking actually happens. A new task flag tells the scheduler to notify io_uring when the submitting thread is about to sleep. At that moment an idle worker takes over the submitting thread's identity — thread ID, signal state, credentials, rseq and robust lists, scheduling attributes, register state — and returns to userspace in its place. The original thread, now carrying the worker's identity, sleeps, finishes the operation, and joins the worker pool. The cover letter's benchmarks show why it is tempting: an fsync test on tmpfs improved by roughly 700 percent, because the handoff cost is now paid only when blocking is real.

The risk sits in the identity exchange itself. Nothing else in the kernel may hold a reference to either thread's task structure at the moment of the swap, so the series carries a long list of disqualifying conditions: threads under ptrace, threads using perf events, kernel-tracked futex ownership, realtime scheduling policy, core-scheduling cookies, an in-progress vfork, and more. Peter Zijlstra noted that shadow stacks — enabled on most current x86 deployments — currently disqualify the handoff too, though Axboe believes the shadow stack can move with the identity. Reception on the list is best summarised by Gabriel Krisman Bertazi's verdict: "really cool and seems like very dangerous thing".

How to read this if you build on io_uring

There is nothing to adopt yet; Axboe himself frames the series as a viability question, not a merge candidate. Two details deserve attention from embedded readers. Realtime scheduling excludes the handoff by design, so PREEMPT_RT systems would keep the current worker-thread behaviour and see none of the gains. And the regressions in the RFC's own numbers appear at high queue depths on operations that always block, so the win is workload-specific.

Orphaned VMs: guests that outlive the host kernel

Pasha Tatashin of Google posted a 46-patch RFC on 20 September that pushes the Live Update Orchestrator one step further. LUO, upstream since 6.19 and built on the Kexec Handover infrastructure, preserves selected state across a kexec reboot so a host kernel can be replaced under running workloads; that base is still being completed upstream. The new proposal keeps virtual machines actually executing instructions while the host kernel is down.

The mechanism is called an orphaned VM: guest vCPUs continue on physical CPUs that are shielded from the reboot, while a small privileged interpose layer named the Caretaker traps VM exits and resolves what it can locally — with no host kernel and no VMM present. The series preserves vCPU file-descriptor state across the reboot gap, protects the reserved CPUs from boot-time reset signals, and deals with timekeeping drift, stray interrupts, and guest-to-guest IPI routing during the window. It has been tried on Intel, AMD and Arm server processors; the author calls it early-stage work seeking feedback, ahead of discussion at the Linux Plumbers Conference in Prague next month.

The pattern matters more than the patches. Cloud providers are systematically removing the reboot as a source of downtime, and the building blocks they are upstreaming — Kexec Handover, LUO, now the Caretaker concept — are generic kernel infrastructure, not cloud-only code.

What it means for fleet and hypervisor designs

Industrial and telecom edge systems have the same problem in a smaller form: a gateway running a hypervisor cannot take the guests down every time the host kernel needs a security update. Nothing here is deployable yet, and the vCPU-preservation work targets large servers first. The realistic action is to study LUO and Kexec Handover now — both are documented in the kernel tree — because kexec-based live update is becoming the upstream answer to host maintenance. Product architectures that assume a full-stack reboot for every kernel fix should be re-examined against it.

Amlogic announces the first Cortex-A320 SoCs

Amlogic has announced the A123X and C305X2, the first announced SoCs built on Arm's Cortex-A320 — the smallest Armv9 core, introduced by Arm in February 2025 with SVE2 vector extensions. The A123X carries four A320 cores for industrial machine vision: dashcams, robots, access control, video conferencing. The C305X2 carries two, aimed at battery devices such as solar doorbells and battery IP cameras, with always-on video and pre-roll low-power modes. Both are fabricated on a 6 nm process and pair the CPUs with Amlogic's 8 TOPS ADLA3 NPU, which accelerates Transformer operators in hardware; both also carry an ADLA2 NPU — rated at 4 TOPS on the A123X for CNN workloads, and serving the AI-ISP on the C305X2 — plus a neural audio-event engine and a low-light AI-ISP.

The vendor's headline numbers: 34 percent higher SPECint2006 than the Cortex-A35 this class of chip typically used, and roughly ten times the ML throughput from SVE2. The software story is thin so far — Linux compatibility, reference designs and NN SDKs are promised, with no public datasheets or block diagrams yet. Chips are sampling now, with mass production scheduled for the fourth quarter of 2026. All details are preliminary and come from the vendor's own announcement.

The significance is the class of device. Camera and doorbell SoCs have run Armv8 little cores for a decade; Armv9 in this segment brings SVE2, and with it a vector baseline that inference libraries can target instead of hand-written NEON paths. On-device Transformer support in an 8 TOPS NPU also signals where vendors expect small-model workloads to run.

How to evaluate the first Cortex-A320 parts

Treat these as roadmap information, not design-in candidates, until an SDK and datasheets exist. The questions that decide usability will be familiar: which kernel version the BSP ships, whether the NPU stack is usable outside the vendor's pipeline, and what the upstreaming position is — none of which the announcement answers. Teams selecting camera silicon for 2027 products should add A320-based parts to the comparison table now and press vendors on the software questions early.

Ubuntu 26.10 finishes the move to Rust coreutils

Canonical has completed a transition that began with Ubuntu 25.10: as of the 26.10 development release, cp, mv and rm come from the Rust coreutils project rather than GNU coreutils. Those three commands had stayed on the GNU implementations through 25.10 and 26.04 LTS because of compatibility issues that upstream uutils has since resolved. The 26.10 draft release notes now record the transition as complete, with the beta due this month and the stable release planned for 15 October, targeting Linux 7.3 as its kernel.

Taken with the Binder item, the pattern is clear: in the same month, the reference C implementation of a core Android kernel driver and the last GNU file utilities in a major distribution are both replaced by Rust implementations. Both moves rest on the same argument — memory-safe reimplementations have reached practical parity.

For embedded teams the relevant surface is scripts. Two decades of shell scripts encode GNU-specific behaviour in rarely used options, exact error messages, and edge-case handling.

How to check your images and scripts

If your build or device images derive from Ubuntu, run your provisioning and CI scripts against a 26.10 beta image before the October release reaches your base-image pipeline. Pay attention to scripts that parse cp, mv or rm output or rely on obscure options, and to anything that assumes GNU-specific error text. Debian-based and Yocto-based images are untouched by this change, but the wider ecosystem trend is worth noting in platform decisions.

References

— Raghu Bharadwaj

If you want to go deeper than the news, TECH VEDA runs live, instructor-led training on Linux kernel internals and embedded Linux — see Linux Kernel Infrastructure.

DEV Community