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

Provide a public interface to preopened directory lookups. #10

Merged
merged 3 commits into from Apr 5, 2019

Conversation

sunfishcode
Copy link
Member

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.

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.
@jedisct1
Copy link
Member

jedisct1 commented Apr 3, 2019

Oh, yes, please!

@alexcrichton
Copy link
Collaborator

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 int error code perhaps? It seems a bit wonky to reach inside the struct to see if it returned an invalid fd as opposed to treating it like most other libc functions which return an error code.

@sunfishcode
Copy link
Member Author

@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?

@alexcrichton
Copy link
Collaborator

Looks great to me!

@sunfishcode sunfishcode merged commit 685d014 into master Apr 5, 2019
@sunfishcode sunfishcode deleted the preopen-symbols branch April 5, 2019 13:30
alexcrichton added a commit to alexcrichton/rust that referenced this pull request Apr 5, 2019
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!
@alexcrichton
Copy link
Collaborator

I'm integrating this into Rust with rust-lang/rust#59727 and some quick local testing shows it working perfectly!

Centril added a commit to Centril/rust that referenced this pull request Apr 5, 2019
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!
Centril added a commit to Centril/rust that referenced this pull request Apr 5, 2019
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!
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.

None yet

3 participants