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

Remove WASI Core API #1461

Merged
merged 3 commits into from
Sep 7, 2019
Merged

Remove WASI Core API #1461

merged 3 commits into from
Sep 7, 2019

Conversation

newpavlov
Copy link
Contributor

@newpavlov newpavlov commented Aug 9, 2019

Closes #1434

This change does not break the backwards compatibility promise since WASI Core API is unstable right now. If applications or libraries want to use Core API directly they should use wasi instead of libc.

Blocked by: rust-lang/rust#63676

cc @sunfishcode

@rust-highfive
Copy link

r? @gnzlbg

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

@gnzlbg
Copy link
Contributor

gnzlbg commented Aug 9, 2019 via email

@bors
Copy link
Contributor

bors commented Aug 9, 2019

✌️ @sunfishcode can now approve this pull request

@gnzlbg
Copy link
Contributor

gnzlbg commented Aug 12, 2019

@sunfishcode this needs your review
cc @alexcrichton maybe?

@alexcrichton
Copy link
Member

I do not agree with this change and would not remove this API. Instability inherent with a platform will of course cause instability in the libraries for the platform, and no one's expecting the libc crate to make a breaking change when the wasi api changes.

@newpavlov
Copy link
Contributor Author

newpavlov commented Aug 12, 2019

@alexcrichton
Do you believe that libc is a correct place for exposing (unstable) WASI Core API, even considering the existence of the dedicated wasi crate? Or are you hesitant to introduce a breaking change with such removal?

If it's the latter, I guess we could mark those functions deprecated for the time being, but I think eventually WASI Core API should be removed from libc.

@alexcrichton
Copy link
Member

Yes, I believe libc is the right place for these APIs. They're in the header files in the C implementation, so libc seems like the place to put them.

I would also not go as far as marking them deprecated. We'll just follow what wasi does in C, and if that breaks then the Rust target will break. Again no one is expecting the libc crate to have a breaking version bump for the wasi target. Everything about wasi is unstable and breaking and changing.

@sunfishcode
Copy link
Member

This path is growing on me. The reason these things on the C side are declared in WASI libc is mainly that we don't have a package manager for C so it's convenient to have everything live in one place. But the WASI interfaces are logically a layer below the rest of libc.

@newpavlov This patch should probably also remove the various __wasi_* types. And, what would you think about removing all the various __WASI_* constants too, and importing them from the wasi crate, as needed, instead?

@newpavlov
Copy link
Contributor Author

@sunfishcode
Ah, yes, I have indeed overlooked __wasi_* types. I am not sure about importing constants from wasi though. Can't we simply duplicate them? For example for Fuchsia libc duplicates constants instead of importing them from Fuchsia crates.

@newpavlov
Copy link
Contributor Author

I have removed __wasi_* types and __WASI_* constants, but left __wasilibc_* functions untouched.

sunfishcode added a commit to CraneStation/wasi-misc-tests that referenced this pull request Aug 13, 2019
Switch from depending on libc to depending on the new wasi crate to provide
the low-level WASI interfaces.

See also rust-lang/libc#1461.
@sunfishcode
Copy link
Member

Overall this looks good.

I'm wondering if there's anything else we can do about the __WASI_* constants though. WASI is less stable than Fuchsia at this point, and some of these constants could very well change at the WASI level. Besides the awkwardness for maintainers to keep everything in sync, it's awkward for end users if eg __WASI_O_CREAT ever changes, because then their open(..., O_CREAT) code would break. It doesn't say which WASI version it's using. But, I'm not sure if there's anything we can do about that.

@alexcrichton
Copy link
Member

I'm fine deferring to @sunfishcode's judgement here, but to avoid another debacle of updating libc in rust-lang/rust I'd request that the reliance of libstd on these symbols is removed before this PR is merged.

@newpavlov
Copy link
Contributor Author

@sunfishcode
Can you add removed types and constants to wasi? After that I can help with migrating rust-lang/rust to wasi if you want.

@sunfishcode
Copy link
Member

@newpavlov The current wasi package has all the types and constants in it.

@newpavlov
Copy link
Contributor Author

@sunfishcode What should I do with __wasilibc_find_relpath? It uses __wasi_rights_t, should I duplicate it in libc?

sunfishcode added a commit to CraneStation/wasi-misc-tests that referenced this pull request Aug 19, 2019
Switch from depending on libc to depending on the new wasi crate to provide
the low-level WASI interfaces.

See also rust-lang/libc#1461.
@sunfishcode
Copy link
Member

Yeah, I think it's fine to duplicate the definition of __wasi_rights_t here for now. That said, it may change, but that's just another instance of a more general problem.

Centril added a commit to Centril/rust that referenced this pull request Sep 5, 2019
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this pull request Sep 6, 2019
Centril added a commit to Centril/rust that referenced this pull request Sep 6, 2019
@newpavlov
Copy link
Contributor Author

rust-lang/rust#63676 has landed, so this PR is not blocked anymore.

@gnzlbg
Copy link
Contributor

gnzlbg commented Sep 7, 2019

@bors: r+

@bors
Copy link
Contributor

bors commented Sep 7, 2019

📌 Commit 078a748 has been approved by gnzlbg

@bors
Copy link
Contributor

bors commented Sep 7, 2019

⌛ Testing commit 078a748 with merge fdbcc11...

bors added a commit that referenced this pull request Sep 7, 2019
Remove WASI Core API

Closes #1434

This change does not break the backwards compatibility promise since WASI Core API is unstable right now. If applications or libraries want to use Core API directly they should use [`wasi`](https://crates.io/crates/wasi) instead of `libc`.

Blocked by: rust-lang/rust#63676

cc @sunfishcode
@bors
Copy link
Contributor

bors commented Sep 7, 2019

☀️ Test successful - checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, status-azure
Approved by: gnzlbg
Pushing fdbcc11 to master...

@bors bors merged commit 078a748 into rust-lang:master Sep 7, 2019
@newpavlov newpavlov deleted the patch-4 branch September 7, 2019 22:10
kubkon added a commit to CraneStation/wasi-common that referenced this pull request Nov 7, 2019
* Initial checkin.

* Update to rust-lang libc.

* Add a .gitignore file.

* Factor out functions for cleaning up files and directories.

* Fix a typo in a comment.

* Print a "Success!" message if all tests passed.

* Factor out code for creating directories.

* Add wrappers around WASI functions.

These wrappers handle converting from &str to pointer+length and handle
unsafe.

* More refactoring.

* Refactor a fd_close helper.

* Move utility functions into a separate file.

* cargo update

* Add a basic test for random_get.

* Test that directories aren't resizable.

* Test clearing __WASI_RIGHT_PATH_FILESTAT_SET_SIZE.

Ensure that clearing __WASI_RIGHT_PATH_FILESTAT_SET_SIZE succeeds before
testing file truncation.

* cargo update

* Modularise tests for easier use with wasi-common crate

* Add a Code of Conduct and CONTRIBUTING.md.

* Fix typo

* Add testcase for fd_allocate

* Add positive test for fd_renumber

* Assert bufused in readlink_no_buffer testcase

* Add positive readlink testcase

* Add testcase for fd_seek and fd_tell

* Add fd_p{read, write} test

* Add README

* Add cases with trailing slashes to interesting_paths

* Split nofollow_errors testcase into two

* nofollow_errors now operators on symlinks to existing resources
* dangling_symlink covers danling symlinks tests

* Factor out a `create_file` helper function.

* Switch from the error crate to `std::io::Error::last_os_error()`.

* Use `create_file` in the readlink test too.

* Add a test for fd_filestat_set_*

* Minor refactoring

Add missing cleanup_file calls to file_pread_pwrite and
file_seek_tell.

* Add testcase for unbuffered fd_write; fixes #11

* Add testcase for path_rename

* Use the wasi crate.

Switch from depending on libc to depending on the new wasi crate to provide
the low-level WASI interfaces.

See also rust-lang/libc#1461.

* Add a test for path_filestat_*

* Add a test for fd_readdir

* Use expect instead of unwrap

* Add a check for ino.

* Fix the build

* Don't assume a specific order of dirents

* Better test

* Test cookie value

* Fix file types

* Fix the test

* Fix the test

* Fix the test

* Cleanup

* Minor formatting tidying in README.md.

* Fix miscellaneous clippy warnings.

* Rename the crate to wasi-misc-tests.

* Update to wasi 0.7.0.

This switches from using the libc wasi bindings to using the wasi
crate's bindings. This eliminates a git dependency on libc, updates
to the new-style bindings which use Result where possible, and treats
functions that operate on raw file descriptors as unsafe.

* Add various tests for trailing-slash behavior.

* Sync new testcases with latest upstream

* Fix path_filestat testcase

* Add smoke test for fd_advise

This test is a true smoke test as it only tests whether issuing
an advise call to the host's kernel doesn't yield an error. The
consequence of issuing such a syscall is not tested.

* Check if CLOCK_MONOTONIC is actually monotonic

* Refactor the inequality assertions for more debuggable errors.

* Bump libc from 0.2.62 to 0.2.65

Bumps [libc](https://github.com/rust-lang/libc) from 0.2.62 to 0.2.65.
- [Release notes](https://github.com/rust-lang/libc/releases)
- [Commits](rust-lang/libc@0.2.62...0.2.65)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

* Fix compilation error

* Enable Actions and add rust.yml (#35)

* Enable Actions and add rust.yml

This commit enables Github Actions and adds corresponding configuration in rust.yml file.

* Update rust.yml

* Fix formatting

* Add empty .rustfmt.toml config file

* Add badge to README

* Update README

* Clean up Github Actions and README

* Add test case for `poll_oneoff` syscall (#38)

* Add test case for `poll_oneoff` syscall

This commit adds a test case for `poll_oneoff` syscall. In particular,
it builds on the excellent test use case provided by @dunnock in their
repo [poll_oneoff_tests] (thanks!), and tests:
* simple timeout
* stdin read with timeout
* fd read and fd write polls

[poll_oneoff_tests]: https://github.com/dunnock/poll_oneoff_tests

* Apply suggestions and negative test for bad fd

Co-authored-by: Maxim Vorobjov <maxim.vorobjov@gmail.com>

* Add smoke test for STDOUT/ERR readwrite poll

* Add comment on stdin/out/err

* Add a test for `*at`-style functions returning `ENOTDIR` when `dirfd` is not a dir.

* Remove misc_testsuite submodule

* Add "publish=false" to Cargo.toml; remove LICENSE
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.

Status of WASI Core API
6 participants