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

wasi: Use shared API for preopened fds #59727

Merged
merged 1 commit into from
Apr 6, 2019
Merged

Conversation

alexcrichton
Copy link
Member

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!

@rust-highfive
Copy link
Collaborator

r? @aidanhs

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label 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
Member Author

r? @fitzgen

@Centril
Copy link
Contributor

Centril commented Apr 5, 2019

@alexcrichton Can't you just give @fitzgen r+ rights and make highfive listen? :P

@fitzgen
Copy link
Member

fitzgen commented Apr 5, 2019

@bors r+

@bors
Copy link
Contributor

bors commented Apr 5, 2019

📌 Commit bb2c0d1 has been approved by fitzgen

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 5, 2019
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!
bors added a commit that referenced this pull request Apr 5, 2019
Rollup of 6 pull requests

Successful merges:

 - #58894 (Fix invalid bounds string generation in rustdoc)
 - #59599 (Updated RELEASES.md for 1.34.0)
 - #59624 (SGX target: Use linker option to avoid code CGU assignment kludge)
 - #59696 (Remove invalid assertion back::link::from add_upstream_rust_crates().)
 - #59707 (Add missing tryfrom example)
 - #59727 (wasi: Use shared API for preopened fds)

Failed merges:

r? @ghost
@bors bors merged commit bb2c0d1 into rust-lang:master Apr 6, 2019
@alexcrichton alexcrichton deleted the wasi-apis branch May 1, 2019 17:49
sunfishcode added a commit to CraneStation/wasi that referenced this pull request Jun 5, 2019
In addition to using the new triple, this arranges for users get the
following fixes:
 - rust-lang/rust#60117
 - rust-lang/rust#59727
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants