-
Notifications
You must be signed in to change notification settings - Fork 166
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
openat2 extensibility #1186
Comments
Rustix tends to avoid "just pass the bits through" interfaces, because one of rustix's big goals is safe APIs. |
Oh, rereading this, I think I may have misunderstood your request here. Perhaps you're not asking to expose the raw Linux I looked a little at libpathrs and don't see a place where |
We don't expose it in libpathrs, this is mainly a request as a user of However (as the author of This would also allow libraries that expose |
The kernel API for
openat2
is designed to be extensible but the API binding provided by rustix is done in a way that would result in API breakage if a new field was added toopenat2
in the future. Ideally, the API would look something more like (idk ifAsRef<Openat2How>
orInto<Openat2How>
is more preferable):Sadly, the most ergonomic way of instantiating
Openat2How
wouldn't work:because
#[non_exhaustive]
blocks that too. But they could at least do:And then
rustix
would usestd::mem::size_of::<Openat2How>()
as the size argument to the syscall. This would allow for future extensions to be added toOpenat2How
transparently without causing breakages for Rust users -- allowing us to provide the same backward-compatibility that C users ofopenat2
get.Because of this limitation, I can't switch my last syscall wrapper in libpathrs from raw
libc
calls torustix
because I sometimes test extensions in my Rust code and the current API doesn't let you express extensions.Since changing this would be a breakage and would require a new minor bump for rustix, I'm opening an issue before sending a PR for this. If this API would a bit too ugly to use for most people, then maybe we could make it
openat2_raw
or something?The text was updated successfully, but these errors were encountered: