-
Notifications
You must be signed in to change notification settings - Fork 204
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
Provide a public interface to preopened directory lookups. #10
Conversation
For users of especially non-C compilers, provide an API for looking up preopened directories. This is used internally in WASI libc to translate from eg. `open` to `openat`, but it can now also be used by user code.
Oh, yes, please! |
Thanks @sunfishcode! For posterity this solves a relatively core problem that came up in the development of rust-lang/rust#59619 which was how to best implement absolute-path-taking-APIs outside of libc itself (aka in the Rust standard library), and an interface like this ended up being perfect for our use case! The only comment I'd have is I wonder if it'd be best to return an |
Just return the file descriptor, and use an out parameter for the relative path.
@alexcrichton Ok, I adjusted the function a little to return the file descriptor, or -1 on failure like a typical C function. It provides the relative path via an out parameter. Does that make sense? |
Looks great to me! |
This commit updates the wasi target with supported added in WebAssembly/wasi-libc#10. That function allows both C and Rust to cooperate in how preopened files are managed, enabling us to learn about propened files through the same interface. The `open_parent` function in the wasi `fs` module was updated to avoid its own initialization of a global preopened map and instead delegate to libc to perform this functionality. This should both be more robust into the future in terms of handling path logic as well as ensuring the propened map is correctly set up at process boot time. This does currently require some unfortunate allocations on our side, but if that becomes an issue we can always paper over those in time!
I'm integrating this into Rust with rust-lang/rust#59727 and some quick local testing shows it working perfectly! |
wasi: Use shared API for preopened fds This commit updates the wasi target with supported added in WebAssembly/wasi-libc#10. That function allows both C and Rust to cooperate in how preopened files are managed, enabling us to learn about propened files through the same interface. The `open_parent` function in the wasi `fs` module was updated to avoid its own initialization of a global preopened map and instead delegate to libc to perform this functionality. This should both be more robust into the future in terms of handling path logic as well as ensuring the propened map is correctly set up at process boot time. This does currently require some unfortunate allocations on our side, but if that becomes an issue we can always paper over those in time!
wasi: Use shared API for preopened fds This commit updates the wasi target with supported added in WebAssembly/wasi-libc#10. That function allows both C and Rust to cooperate in how preopened files are managed, enabling us to learn about propened files through the same interface. The `open_parent` function in the wasi `fs` module was updated to avoid its own initialization of a global preopened map and instead delegate to libc to perform this functionality. This should both be more robust into the future in terms of handling path logic as well as ensuring the propened map is correctly set up at process boot time. This does currently require some unfortunate allocations on our side, but if that becomes an issue we can always paper over those in time!
For users of especially non-C compilers, provide an API for looking up
preopened directories. This is used internally in WASI libc to translate
from eg.
open
toopenat
, but it can now also be used by user code.