Rustix for android, part deux#1577
Rustix for android, part deux#1577gurchetansingh wants to merge 4 commits intobytecodealliance:mainfrom
Conversation
gurchetansingh
commented
Feb 2, 2026
These ioctl wrappers are used by rustix users. For example: https://github.com/Smithay/drm-rs/blob/develop/drm-ffi/src/ioctl.rs#L6 Roughly, they match the ones provided by nix. I'm upstreaming the portion I have personally tested.
Android likes to build host tools (adb, Cuttlefish, ..) via musl, using the same hermetic tree as for Bionic build. And linux-raw-sys isn't in that hermetic tree, so add support for the libc-backend.
It's desirable to enable futex for some cases that will be run on Android. The strategy is just to define the constants needed by the libc ourselves, if libc doesn't provide the necessary constant. Long-term, that could make the libc backend only depend on libc.
Rustix has gone back-and-forth on it's policy on Android. Android platform developers don't want a dependency on linux-raw-sys. This is documented here: bytecodealliance#1095 bytecodealliance#1478 rust-vsock/vsock-rs#60 Android app developers seem to want to use linux-raw-sys though: bytecodealliance#1528 The Android platform developers don't REALLY care about the cargo build though. CI/CD testing on the particular build options Android likes is useful. This MR adds another non-cargo build system (Meson) to the CI/CD, that mirrors the options Android likes. Meson is renowned for being a easy-to-maintain build system. By adding it here, we ensure the continue use of Rustix in core Android platform code.
e97ec4e to
f5b00ae
Compare
|
Also, getting a new release for this would be most terrific for downstream integrators. |
|
|
||
| /// Convenience macro for Rustix's ioctl read | ||
| #[macro_export] | ||
| macro_rules! ioctl_readwrite { |
There was a problem hiding this comment.
These seem like weird inclusions for the public API.
There was a problem hiding this comment.
so nix has them too:
https://github.com/nix-rust/nix/blob/master/src/sys/ioctl/mod.rs#L652
I know of two places that are duplicating this logic:
https://github.com/Smithay/drm-rs/blob/develop/drm-ffi/src/ioctl.rs#L6
https://github.com/magma-gpu/rutabaga_gfx/blob/main/third_party/mesa3d/src/magma/sys/linux/amdgpu.rs#L43 (the project I work on)
Anything particularly wrong with these APIs? Otherwise, people have to excessively define things like ioctl::Updater and ioctl::opcode::read_write.
We would like to land: #36 But that'll break Android until the following rustix change lands: bytecodealliance/rustix#1577 and it can take a few months to get something through rustix due to limited maintainer bandwidth. Stopgap solution: cut releases and branches for libkrun until Rustix change is merged. Unlike the "chromeos" branch, the libkrun branch will eventually be merged with main.
We would like to land: #36 But that'll break Android until the following rustix change lands: bytecodealliance/rustix#1577 and it can take a few months to get something through rustix due to limited maintainer bandwidth. Stopgap solution: cut releases and branches for libkrun until Rustix change is merged. Unlike the "chromeos" branch, the libkrun branch will eventually be merged with main.
|
gentle ping. Perhaps added more reviewers/maintainers could help with the backlog? |