Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use rustix instead of nix #147

Closed
notgull opened this issue Sep 4, 2023 · 5 comments
Closed

Use rustix instead of nix #147

notgull opened this issue Sep 4, 2023 · 5 comments

Comments

@notgull
Copy link
Member

notgull commented Sep 4, 2023

This would allow us to use safer, direct system calls instead of libc.

Blocked on bytecodealliance/rustix#797

@ids1024
Copy link
Member

ids1024 commented Oct 4, 2023

With bytecodealliance/rustix#848 and Smithay/wayland-rs#658, we should be able to eliminate nix in the Wayland backend and its dependencies.

But yeah, there's still SYSV shm. Such an annoying API...

@notgull
Copy link
Member Author

notgull commented Oct 5, 2023

It may be possible to rewrite the X backend to use POSIX shared memory as well as attach_fd to get around this issue.

@ids1024
Copy link
Member

ids1024 commented Oct 5, 2023

Yeah. That's an extension added by Xorg that may not be available everywhere, but I'm not sure it's likely to be an issue anywhere softbuffer would be used. This doesn't apply with network transparency anyway, and you're not likely to be running anything other than Xorg otherwise, or an extremely old version of Xorg.

@ids1024
Copy link
Member

ids1024 commented Oct 13, 2023

Actually shm* are imported from nix::libc, so we could just depend on libc directly to eliminate nix there. It could be added to rustix later for a safe API and support for direct syscalls on Linux.

Though like Smithay, the kms backend here uses nix::errno::Errno to compare errors from the drm crate. Which is a bit awkward to deal with.

ids1024 added a commit that referenced this issue Oct 13, 2023
Partly addresses
#147, though it would
still be desirable to have a good safe API for SYSV shm in Rustix. But
using `libc` directly for now is no worse than using the `nix::libc`
re-export, so we don't lose anything.
ids1024 added a commit that referenced this issue Oct 13, 2023
Partly addresses
#147, though it would
still be desirable to have a good safe API for SYSV shm in Rustix. But
using `libc` directly for now is no worse than using the `nix::libc`
re-export, so we don't lose anything.
@ids1024
Copy link
Member

ids1024 commented Nov 9, 2023

I think this can be considered resolved now.

@ids1024 ids1024 closed this as completed Nov 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants