Rust in QEMU Roadmap

Original Article ↗ Hacker News Discussion ↗

Rust’s gradual introduction into QEMU is prompting careful design work around FFI, data-structure interoperability, and tooling, with maintainers aiming to improve safety and expressiveness without abandoning existing C infrastructure. Contributors debate language choices—contrasting Rust with C++ and QEMU’s homegrown object system—and how far to lean on newer Rust features given long-term support needs and complex build environments. A major tension centers on distro packaging, especially Debian’s conservative toolchain policies, which push QEMU to support older Rust versions even as some developers argue this slows adoption of modern language capabilities.

Rust in QEMU and the Kernel

  • Rust is already used for Linux drivers (notably graphics), with upcoming kernel releases adding important support.
  • For QEMU, Rust adoption is gated by the effort to write and maintain FFI glue. Community help is needed, especially for areas like tracepoints.
  • Current Rust work in QEMU focuses on object and threading models, where Rust–C impedance mismatch is largest.

Tracepoints and Tooling

  • QEMU tracepoints mainly use a printf-style backend and USDT.
  • A Python script (tracetool) generates C code for trace backends; idea is to extend it to generate Rust or FFI bindings.
  • Existing Rust USDT crates and related tools are being explored as building blocks.

Rust Language / Ecosystem Wishlist

  • Desired language features: const operator overloading / const traits (e.g., bitflags-like patterns).
  • FFI wishes: easier config for bindgen (TOML/response files), simpler closure-to-C-callback patterns, and some standardized core FFI traits.
  • Pin/PinInit patterns from Rust-for-Linux seem to work well without unstable features.
  • Meson’s Rust support is improving but not yet seamless.

QEMU’s C “Object Model”, OOP, and Rust vs C++

  • Several commenters describe QEMU’s C code as “fake C++”: deep macro use, manual object systems, and difficulty integrating any real C++.
  • Others argue large C projects often build their own “mini-language” on top of C to control memory, I/O, and concurrency tightly.
  • Debate over whether C++ would have been better:
    • Pro-C++ side: you can use a C-like subset plus stronger abstractions; C++ is strictly more expressive.
    • Pro-C side: C++ is huge, unsafe, and full of interacting features; avoiding exceptions, templates, etc. is easier in C than in “restricted C++”.
  • Rust is seen as offering methods, traits, and vtables (enough polymorphism) without C++-style inheritance; some miss “real classes”, others say structs + impls already provide data–method bundling.

Casting and Type Safety

  • Rust’s IsA-style traits enable compile‑time‑checked upcasts with zero runtime cost.
  • A C technique using unions to encode full base-class chains is discussed; some maintain it yields similar compile-time safety, others warn about non-portable union type-punning per the C standard.

Rust Toolchains, Distros, and Stability

  • Large subthread on why QEMU targets distro Rust rather than rustup:
    • Distros require building entirely from their own repositories, offline, and reproducibly.
    • They repackage Cargo dependencies and cannot depend on external services like rustup.
  • QEMU wants to remain easy to package and secure via distro backports, so it aligns its minimum supported Rust version with major distro toolchains, even if they lag by years.
  • Some criticize Debian and similar distros for slow toolchain updates and argue this forces upstreams into workarounds; others frame this as a deliberate, conservative stability model.
  • There is discussion of Rust’s fast 6‑week release cadence and the fact that new std methods can theoretically break compiling older code in edge cases.

rustup and Installation Safety

  • rustup previously had an uninstall behavior that could rm -rf its install prefix, causing accidental data loss if run in system directories.
  • curl‑to‑shell installers are criticized as bad security hygiene and user education, even if widely used; comparisons are made to the risks of adding arbitrary package repositories.