Skip to content

Port vsock-rs to use rustix#60

Draft
notgull wants to merge 1 commit intorust-vsock:masterfrom
forkgull:notgull/rustix
Draft

Port vsock-rs to use rustix#60
notgull wants to merge 1 commit intorust-vsock:masterfrom
forkgull:notgull/rustix

Conversation

@notgull
Copy link

@notgull notgull commented Dec 23, 2025

vsock-rs currently uses a mix of nix and libc to handle
the underlying system calls. However, in addition to adding
a few extra dependencies, this means that there is a significant
amount of unneeded unsafe code in the project.

By porting to "rustix", we gain the following advantages:

  • Most of the code in the project can be rewritten completely
    safely.
  • We avoid going through libc. In other projects this has been
    benchmarked to lead to a 2.5% performance increase.
  • On Linux, we reduce the number of dependencies the project
    pulls in. On other platforms, it stays the same.

This is a breaking change, since this crate exposes primitives from nix; specifically "VsockAddr". I've added a new "SocketAddr" type that exposes no types from any subcrates.

Blocked on bytecodealliance/rustix#1558

@qwandor qwandor self-requested a review December 23, 2025 12:41
@jalil-salame jalil-salame self-requested a review December 23, 2025 13:26
@qwandor
Copy link
Contributor

qwandor commented Dec 23, 2025

Avoiding unsafe code is nice, but I don't think we should be avoiding going through libc. In particular on Android, where we use this crate in several parts of the platform, there are a number of places where libc has important platform logic (e.g. for tracking file descriptors) that shouldn't be skipped, and so we would like to avoid using rustix.

If there are some more safe wrappers in nix that we can use then I'm happy with moving to those rather than calling directly into libc.

@notgull
Copy link
Author

notgull commented Dec 23, 2025

there are a number of places where libc has important platform logic (e.g. for tracking file descriptors) that shouldn't be skipped

rustix has a feature named use-libc that makes it so it always uses libc, even on Linux. So there's still an option with rustix to use the libc backend. This just introduces the option to use raw Linux system calls.

If this still worries you, the libc backend is always used on Android for the reasons you bring up.

@qwandor
Copy link
Contributor

qwandor commented Dec 23, 2025

Unfortunately as of bytecodealliance/rustix#1528 rustix uses linux-raw-sys on Android too, despite the discussion in bytecodealliance/rustix#1095. Practically, this means we can't use it in the Android platform without downstream patches, which will become more difficult to maintain if rustix continues to move in this direction. So my vote is against using rustix in vsock-rs.

@notgull
Copy link
Author

notgull commented Dec 23, 2025

If it comes to this, we can just enable libc in rustix for Android specifically.

@notgull
Copy link
Author

notgull commented Dec 23, 2025

Actually, my understanding of the above PR is that it isn't making Android use the raw system call backend. Even if use-libc is disabled, Android will still use the libc as the backend. This just brings in the linux-raw-sys crate for some constants.

vsock-rs currently uses a mix of nix and libc to handle
the underlying system calls. However, in addition to adding
a few extra dependencies, this means that there is a significant
amount of unneeded unsafe code in the project.

By porting to "rustix", we gain the following advantages:

- Most of the code in the project can be rewritten completely
  safely.
- We avoid going through libc. In other projects this has been
  benchmarked to lead to a 2.5% performance increase.
- On Linux, we reduce the number of dependencies the project
  pulls in. On other platforms, it stays the same.

Blocked on bytecodealliance/rustix#1558

Signed-off-by: John Nunley <dev@notgull.net>
gurchetansingh added a commit to gurchetansingh/rustix that referenced this pull request Feb 2, 2026
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 added a commit to gurchetansingh/rustix that referenced this pull request Feb 2, 2026
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 added a commit to gurchetansingh/rustix that referenced this pull request Feb 2, 2026
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 added a commit to gurchetansingh/rustix that referenced this pull request Feb 23, 2026
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 and
arguably the favorite among Linux-distro maintainers.

Right now, meson currently does not use Cargo.toml as a source
of truth for dependency, since a dependency's build.rs file can
basically do anything, and there's no way for an external build
system to determine a build.rs file is doing [1].  As such,
the standard way to include dependencies is are meson subprojects,
for each dependency.  There are various proposals to improve the
situation [2], but those would require a bleeding edge meson
not in CI/CD bots yet.

That said, there's an easy way to test from the root of the
directory:
   sudo apt install meson ninja-build
   meson setup rustix-build
   ninja -C rustix-build

Meson closely mirrors what Android does.  By adding it here, we
ensure the continue use of Rustix in core Android platform code.

[1] mesonbuild/meson#2173
[2] mesonbuild/meson#15223
#[cfg(target_os = "macos")]
let flags = SockFlag::empty();
Ok(socket(AddressFamily::Vsock, ty, flags, None)?)
let flags = net::SocketFlags::empty();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Behavior change? We set CLOEXEC outside of macos

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants