Rustix for android, part deux by gurchetansingh · Pull Request #1577 · bytecodealliance/rustix

gurchetansingh · 2026-02-02T17:18:56Z

rustix: add Meson build to CI to guard Android use cases

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:

  https://github.com/bytecodealliance/rustix/issues/1095
  https://github.com/bytecodealliance/rustix/pull/1478
  https://github.com/rust-vsock/vsock-rs/pull/60

Android app developers seem to want to use linux-raw-sys though:

https://github.com/bytecodealliance/rustix/pull/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 · 2026-02-03T01:44:12Z

CC: @sunfishcode @qwandor @HemantKArya

gurchetansingh · 2026-02-04T21:24:08Z

Also, getting a new release for this would be most terrific for downstream integrators.

notgull · 2026-02-05T04:22:17Z

+
+/// Convenience macro for Rustix's ioctl read
+#[macro_export]
+macro_rules! ioctl_readwrite {


These seem like weird inclusions for the public API.

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.

@notgull Do you have any further thoughts here?

Could you write down what these new macros do that can't be done with rustix's existing ioctl API?

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.

gurchetansingh · 2026-02-19T23:48:32Z

gentle ping. Perhaps added more reviewers/maintainers could help with the backlog?

sunfishcode

Thanks for your help!

sunfishcode · 2026-02-21T15:42:36Z

+
+/// Convenience macro for Rustix's ioctl read
+#[macro_export]
+macro_rules! ioctl_readwrite {


@notgull Do you have any further thoughts here?

gurchetansingh · 2026-03-13T22:42:49Z

@sunfishcode ping

gurchetansingh · 2026-04-24T21:30:01Z

CI/CD failures look related to #1606, it passed last time I tried.

This contains downstream patches for Rustix, from: bytecodealliance/rustix#1577 I think the people are cool with the changes generally, but we're essentially running into https://xkcd.com/2347/ right now. The cost of local patches in Rustix now is lower than forking mesa3d_util and friends indefinitely.

This contains downstream patches for Rustix, from: bytecodealliance/rustix#1577 I think the people are cool with the changes generally, but we're essentially running into https://xkcd.com/2347/ right now and the maintainer doesn't have time to even look at it. To ease in the development of mesa3d_util, it's better to keep 3 downstream patches here, than potentially diverging mesa3d_util for actual consumers. Reviewed-by: LingMan Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41321>

gurchetansingh · 2026-10-29T20:07:22Z

@gurchetansingh needs a rebase for CI

@xtqqczze @sunfishcode

Rebased! Good to see the project is accepting patches again. PTAL!

sunfishcode

The meson build seems to require embedding a lot of version strings, hash codes, and build metadata in the rustix repository which will be a chore to maintain.

If the goal is to test rustix with the set of cfgs that Android developers would use, would that be possible to acheve using cargo? Even if cargo isn't how Android developers themselves would actually use it, could we test the needed cfgs that way?

sunfishcode · 2026-11-13T17:22:20Z

+
+/// Convenience macro for Rustix's ioctl read
+#[macro_export]
+macro_rules! ioctl_readwrite {


Could you write down what these new macros do that can't be done with rustix's existing ioctl API?

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.

Android platform developers (AOSP) and external build systems like Meson build rustix with the libc backend and without linux-raw-sys (--cfg=rustix_no_linux_raw): bytecodealliance#1095 bytecodealliance#1478 rust-vsock/vsock-rs#60 Meanwhile, Android app developers using Cargo may want linux-raw-sys enabled by default: bytecodealliance#1528 Gate the linux-raw-sys target dependencies in Cargo.toml on not(rustix_no_linux_raw), ensure --cfg=rustix_no_linux_raw implies the libc backend in build.rs, and test both configurations (with and without rustix_no_linux_raw) on Android and musl targets in CI. To locally test the no-linux-raw-sys path on Android: rustup target add aarch64-linux-android RUSTFLAGS="--cfg rustix_no_linux_raw" cargo check \ --target=aarch64-linux-android \ -F use-libc,net,std,alloc,event,fs,mm,param,pipe,thread \ -F use-libc-auxv,libc_errno \ --all-targets And to verify linux-raw-sys is excluded from the dependency graph: RUSTFLAGS="--cfg rustix_no_linux_raw" cargo tree --edges normal \ --target=aarch64-linux-android \ -F use-libc,net,std,alloc,event,fs,mm,param,pipe,thread \ -F use-libc-auxv,libc_errno

gurchetansingh · 2026-11-13T22:43:27Z

If the goal is to test rustix with the set of cfgs that Android developers would use, would that be possible to acheve using cargo? Even if cargo isn't how Android developers themselves would actually use it, could we test the needed cfgs that way?

It's important to make the distinction between:

Android platform developers -- i.e, the official Android Rust team
Android app developers

My original CL fixed the issue for Android platform developers:

#1478

But Android app developers undid that change:

#1528

I didn't think it was possible for cargo to test two Android configurations (one with linux-raw-sys and one without linux-raw-sys), so I added the meson build system. I had Gemini double check this, and it found a way to make tests both using cargo, and it seems to work. So removed meson.build in the latest MR version.

Could you write down what these new macros do that can't be done with rustix's existing ioctl API?

While they expand to rustix’s existing API, these macros solve three issues:

Ergonomics: Eliminates repetitive const OPCODE declarations (required because Setter/Updater take OPCODE as a const generic) across dozens of driver ioctls.
Ecosystem compatibility: Matches nix’s macro API; at least 3 Rustix-based projects already duplicate this exact wrapper.
Type safety: Opcode is an untyped integer, forcing callers to specify T twice (opcode::read_write::<T> and Updater::<OPCODE, T>). Taking T once prevents UB from type/opcode mismatches.

gurchetansingh force-pushed the rustix-for-android-part-deux branch from e97ec4e to f5b00ae Compare February 2, 2026 22:28

gurchetansingh changed the title ~~[WIP] Rustix for android part deux [WIP]~~ Rustix for android, part deux Feb 3, 2026

gurchetansingh mentioned this pull request Feb 3, 2026

libkrun X11 pipewire support magma-gpu/rutabaga_gfx#36

Closed

notgull reviewed Feb 5, 2026

View reviewed changes

sunfishcode reviewed Feb 21, 2026

View reviewed changes

gurchetansingh force-pushed the rustix-for-android-part-deux branch from f5b00ae to 3ec91c2 Compare February 23, 2026 15:21

gurchetansingh mentioned this pull request Feb 27, 2026

Clarify the purpose of "supports_dmabuf" in CrossDomainCapabilities magma-gpu/rutabaga_gfx#40

Open

gurchetansingh force-pushed the rustix-for-android-part-deux branch from 3ec91c2 to 31c894e Compare April 24, 2026 14:07

gurchetansingh force-pushed the rustix-for-android-part-deux branch from 31c894e to 5fa428d Compare May 1, 2026 22:52

This comment was marked as resolved.

Sign in to view

gurchetansingh force-pushed the rustix-for-android-part-deux branch from 5fa428d to d37956f Compare October 29, 2026 18:29

sunfishcode reviewed Nov 13, 2026

View reviewed changes

gurchetansingh added 4 commits November 13, 2026 12:15

rustix: add ioctl wrappers

a4f85ec

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.

rustix: improve for musl build without linux-raw-sys

2e3add6

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.

gurchetansingh force-pushed the rustix-for-android-part-deux branch from d37956f to 34e00d3 Compare November 13, 2026 22:26

gurchetansingh requested a review from sunfishcode November 13, 2026 22:43

Conversation

gurchetansingh commented Feb 2, 2026

Uh oh!

gurchetansingh commented Feb 3, 2026

Uh oh!

gurchetansingh commented Feb 4, 2026

Uh oh!

notgull Feb 5, 2026

Choose a reason for hiding this comment

Uh oh!

gurchetansingh Feb 6, 2026

Choose a reason for hiding this comment

Uh oh!

sunfishcode Feb 21, 2026

Choose a reason for hiding this comment

Uh oh!

sunfishcode Nov 13, 2026

Choose a reason for hiding this comment

Uh oh!

gurchetansingh commented Feb 19, 2026

Uh oh!

sunfishcode left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

sunfishcode Feb 21, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

gurchetansingh commented Mar 13, 2026

Uh oh!

gurchetansingh commented Apr 24, 2026

Uh oh!

This comment was marked as resolved.

gurchetansingh commented Oct 29, 2026

Uh oh!

sunfishcode left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

sunfishcode Nov 13, 2026

Choose a reason for hiding this comment

Uh oh!

gurchetansingh commented Nov 13, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants