When dual maintenance ends: Rust Binder deletion and the nova-core binding fight

The argument is no longer whether Rust can ship in Linux. It is when the second copy of a subsystem stops being insurance and starts being pure cost, and who pays that cost in review hours, ABI surface, and forced C refactors before the old code can die.

Two threads landed in the same window and made the shift concrete. Carlos Llamas posted a patch to remove the long-standing C Binder driver outright once the Rust implementation reached feature parity and real Android deployment. Almost in parallel, NVIDIA’s Zhi Wang drove large nova-core series for a vGPU manager and VFIO variant path, and the review of that work reopened fights over drvdata layout, power-management helpers, and whether Rust VFIO bindings are a proper solution or a multi-year side quest. Together they mark the passage from proving Rust can live beside C to deciding how aggressively dual maintenance ends.

Llamas did not hedge. "The day has finally come. We are dropping the legacy C implementation of the Binder IPC driver in favor of its Rust version." His case was maintenance reality after more than fifteen years: the C driver had "grown increasingly complex, making it incredibly painful to maintain and land new features without tripping over vulnerabilities." Alice Ryhl’s Rust Binder, he wrote, had not only matched features but could "match and often beat the performance of the C counterpart." Android devices had already run it long enough that "we can no longer call this an "experiment"." The prescription followed: yank the C code, and put every new feature and optimization on the Rust driver alone. Ryhl acked. Greg Kroah-Hartman was on the thread as the Android and driver tree realities met the rust-for-linux list.

That deletion proposal is the cleanest form of the new question. Binder is not a toy sample. It is core IPC for Android. Removing thousands of lines of C binder and allocator logic is a statement that memory-safety and maintainability wins are no longer hypothetical when the replacement is deployed at scale. It also collapses dual review. As long as both drivers exist, every protocol tweak, security fix, and performance change risks two implementations, two bug surfaces, and two sets of reviewers. Llamas’s patch is an explicit bet that concentrating work on Rust reduces vulnerability treadmills more than it concentrates expertise in one language.

NVIDIA’s nova-core work shows the messier form of the same transition. Zhi Wang’s series add the control path to create and manage NVIDIA vGPU instances: guest drivers in Linux or Windows, QEMU as VFIO user, VFIO core, an NVIDIA vGPU VFIO variant driver binding PCI virtual functions, and nova-core on the physical function as vGPU manager with open, close, and reset lifecycle hooks. Later postings split the VFIO variant pieces for separate review and thickened the manager itself: GSP plugin version negotiation, typed RPC, NVKV-encoded setup parameters, bus-mastering state updates to the plugin, per-instance VRAM scrubbing through a copy-engine utility before reuse, and debugfs log paths with self-describing headers so dumps can be decoded against firmware build identity.

That is production virtualization infrastructure written around Rust nova-core, not a proof of concept. It also collides with C framework assumptions. Reviewers zeroed in on how VFIO PCI core expects to reach driver-private state for PM and AER callbacks. Alex Williamson flagged replacing dev_get_drvdata() patterns by embedding a vfio-pci-core pointer in struct pci_dev as "a non-starter as far as having a common PCI-core shared by various drivers." Danilo Krummrich treated the shortcut as a temporary hack and laid out options: PM helpers that take a vfio_pci_core_device pointer directly, a callback or macro to translate from pci_dev, or even a separate PM domain. His deeper objection was architectural. Class-device helpers should not "impose requirements on the bus device private data layout," and hiding PM entirely in the framework is only worthwhile if it avoids "subtle requirements on the driver."

Dave Airlie put concrete C boilerplate on the table: small AER and runtime PM wrappers that fetch drvdata and forward into vfio_pci_core helpers, plus a standard dev_pm_ops table. For on the order of ten drivers, he did not find the volume excessive, and he doubted the value of hiding "what is effectively just standard driver boilerplate." Jason Gunthorpe answered that it was already "alot," that new drivers would keep paying it, and that "this is exactly the kind of boilerplate people have been removing with macros." The disagreement is not aesthetic. It is about whether Rust entry into VFIO forces cleanup of a layering violation now, or whether variants keep copying forwarders forever.

The binding timeline hardened the stakes. Krummrich argued that "having Rust abstractions is pretty much the same as having another driver" for the purpose of judging prerequisite rework, and that the FFI layer already looked more complicated than the abstraction he had drafted. He wanted the "proper solution right away" rather than landing Zhi’s drafted path as an interim. Gunthorpe pushed back on effort and calendar: precondition C reworks, including drvdata, have to count in the total; a new C driver should not need such reworks; and "I cannot forsee rust bindings for vfio until sometime in 2027." His blunt question framed the dual-maintenance anxiety: "Why can't we just go forward with what Zhi already drafted? Do we really need another side quest?" Krummrich’s reply was that the drvdata problem is an existing layering violation, that many other subsystems took Rust without core churn, and that waiting for a calendar year does not by itself change the design debt.

Through-line across Binder and nova-core is the end of the experiment narrative. Binder’s maintainers claim parity, performance, and field deployment, then propose deletion of the C driver so review load and vulnerability surface stop doubling. Nova-core’s vGPU manager pushes Rust into PF lifecycle, GSP RPC, scrubbing, and VFIO consumption, then immediately stresses how much C framework shape must change before a Rust-native path is first-class. One side of the community, illustrated by Llamas, Ryhl, and Krummrich, treats successful Rust implementations as permission to retire C copies and to fix layering so safe abstractions are not forever second-class. The other, illustrated by Williamson, Airlie, and Gunthorpe in the VFIO discussion, treats each Rust-motivated core change as schedule risk, shared-structure hazard, and review contention against an already long VFIO queue.

Technical substance keeps the debate from floating free. Binder deletion is about stopping dual IPC implementations once Android has already voted with devices. VFIO and nova-core are about whether variant drivers must keep owning pci_dev drvdata for PM and error paths, whether macros or typed helpers dissolve that boilerplate, and whether GSP-backed vGPU instance setup can land through C-shaped VFIO first while Rust bindings mature. ABI surface sits underneath both: Binder’s userspace contract must not move when the kernel implementation language does; vGPU lifecycle and VFIO behaviors must stay stable across PF manager and VF variant boundaries even as the manager is Rust.

Where it stands is asymmetric and unresolved. The Binder removal patch is a direct bid to end dual maintenance for a high-visibility driver, with ack from the Rust Binder author and the maintenance pain of the C code cited as the reason. The NVIDIA series continue to expand nova-core’s vGPU manager in public, while VFIO binding and drvdata questions remain contested and unbound to a firm merge story. Nobody has closed whether "feature parity plus deployment" is generally enough to delete C, how much C refactor cost can be billed to Rust enablement, or who carries review load when the second implementation is the one being kept. The community has moved the question from can Rust live here to when the duplicate C copy is allowed to die. The answer is still being negotiated per subsystem, under real pressure from Android’s Binder cutover and NVIDIA’s vGPU roadmap.