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
gurchetansingh
commented
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.
gurchetansingh
force-pushed
the
rustix-for-android-part-deux
branch
from
e97ec4e to
f5b00ae
Compare
gurchetansingh
changed the title
|
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? |
| #[cfg(not(target_env = "musl"))] | ||
| const STATX__RESERVED: u32 = c::STATX__RESERVED as u32; | ||
| #[cfg(target_env = "musl")] | ||
| const STATX__RESERVED: u32 = linux_raw_sys::general::STATX__RESERVED; |
There was a problem hiding this comment.
Can we be sure that the value of STATX__RESERVED won't change in future Linux versions?
| pub const STATX_ATTR_MOUNT_ROOT: u64 = 0x00020000; | ||
| pub const STATX_ATTR_VERITY: u64 = 0x00100000; | ||
| pub const STATX_ATTR_DAX: u64 = 0x00200000; | ||
| } |
There was a problem hiding this comment.
Constants like these are commonly provided by libc: https://docs.rs/libc/latest/libc/constant.STATX_TYPE.html. At a quick glance, they don't appear to be in the linux-musl targets though.
In general, it would nicer to add these constants to the libc crate, so that rustix doesn't need to have big lists of magic numbers like this.
I think this code is ok for now, but please add TODO comments for these saying that they should be upstreamed into libc.
|
|
||
| /// Convenience macro for Rustix's ioctl read | ||
| #[macro_export] | ||
| macro_rules! ioctl_readwrite { |
| '--cfg', 'libc_ptr_addr_of', | ||
| '--cfg', 'libc_underscore_const_names', | ||
| '--cfg', 'libc_union', | ||
| ] |
There was a problem hiding this comment.
I'm unfamiliar with meson. Can you say more about why rustix needs to have all these configuration files for its dependencies, here in rustix's own tree?
3 participants
