the original C implementation was derived directly from cloudabi-utils.
that implementation is no longer in tree.
acfoltzer's initial Rust implementation included a path_open function
that was ported from cloudabi-utils. this rewrite of wasi-common has
completely delegated all path lookup functionality to cap-std (in the
cap-std-sync impls), and cap-std itself has a completely re-designed
method of path resolution.
This makes fstat work for stdout, stdin and stderr as expected.
This seemed like the only reasonable functions to implement from the
filestat_* set, for stdout, stdin and stderr.
Fixes#2515
Android always has `utimensat` available, so it is not necessary (or
possible, for that matter) to emulate it. Mark the fallback path as
`unreachable!()`.
`fd_readdir` returns a "bufused" value, which indicates the number of
bytes read into the buffer. WASI libc expects this value to be equal
to the size of the buffer if the end of the directory has not yet
been scanned.
Previously, wasi-common's `fd_readdir` was writing as many complete
entries as it could fit and then stopping, but this meant it was
returning size less than the buffer size even when the directory had
more entries. This patch makes it continue writing up until the end
of the buffer, and return that number of bytes, to let WASI libc
know that there's more to be read.
Fixes#2493.
This commit deletes the old `snapshot_0` implementation of wasi-common,
along with the `wig` crate that was used to generate bindings for it.
This then reimplements `snapshot_0` in terms of
`wasi_snapshot_preview1`. There were very few changes between the two
snapshots:
* The `nlink` field of `FileStat` was increased from 32 to 64 bits.
* The `set` field of `whence` was reordered.
* Clock subscriptions in polling dropped their redundant userdata field.
This makes all of the syscalls relatively straightforward to simply
delegate to the next snapshot's implementation. Some trickery happens to
avoid extra cost when dealing with iovecs, but since the memory layout
of iovecs remained the same this should still work.
Now that `snapshot_0` is using wiggle we simply have a trait to
implement, and that's implemented for the same `WasiCtx` that has the
`wasi_snapshot_preview1` trait implemented for it as well. While this
theoretically means that you could share the file descriptor table
between the two snapshots that's not supported in the generated bindings
just yet. A separate `WasiCtx` will be created for each WASI module.
* Enhance wiggle to generate its UserErrorConverstion trait with a function that returns
a Result<abi_err, String>. This enhancement allows hostcall implementations using wiggle
to return an actionable error to the instance (the abi_err) or to terminate the instance
using the String as fatal error information.
* Enhance wiggle to generate its UserErrorConverstion trait with a function that returns
a Result<abi_err, String>. This enhancement allows hostcall implementations using wiggle
to return an actionable error to the instance (the abi_err) or to terminate the instance
using the String as fatal error information.
* Enhance the wiggle/wasmtime integration to leverage new work in ab7e9c6. Hostcall
implementations generated by wiggle now return an Result<abi_error, Trap>. As a
result, hostcalls experiencing fatal errors may trap, thereby terminating the
wasmtime instance. This enhancement has been performed for both wasi snapshot1
and wasi snapshot0.
* Update wasi-nn crate to reflect enhancement in issue #2418.
* Update wiggle test-helpers for wiggle enhancement made in issue #2418.
* Address PR feedback; omit verbose return statement.
* Address PR feedback; manually format within a proc macro.
* Address PR feedback; manually format proc macro.
* Restore return statements to wasi.rs.
* Restore return statements in funcs.rs.
* Address PR feedback; omit TODO and fix formatting.
* Ok-wrap error type in assert statement.
I don't think this has happened in awhile but I've run a `cargo update`
as well as trimming some of the duplicate/older dependencies in
`Cargo.lock` by updating some of our immediate dependencies as well.