Commit Graph

9 Commits

Author SHA1 Message Date
whitequark
476ee59774 Define local seekdir and telldir prototypes on Android.
These functions are not yet defined in the `libc` crate.
See https://github.com/rust-lang/libc/pull/1996.
2020-12-14 22:03:43 -08:00
Dan Gohman
cf5289c553 Begin porting yanix to WASI.
This isn't complete yet, but subsequent steps will depend on Rust libstd
and libc bindings changes that are in flight.
2020-07-06 20:20:28 +02:00
Jakub Konka
bd5e71b038 [wasi-common]: add armv7 support to wasi-common (#1269)
* Add armv7 support to wasi-common

This commit enables `target_pointer_width = 32` compatibility for
`wasi-common` (and by transitivity, any crate found inside, e.g., `yanix`).
I've also added a simplistic (bare minimum) check to our CI to ensure
that `wasi-common` cross-compiles to `armv7-unknown-gnueabihf` fine.
While here, I've done the same for `wasm32-unknown-emscripten`.

* Clean arch-specific impls + reuse libc consts

* Make SeekLoc::from_raw platform independent

* Collapse CI cc jobs into one
2020-03-10 19:18:59 +01:00
Jakub Konka
42fae4e3b8 [wasi-common]: yanix now returns io::Error directly (#1242)
* Yanix now returns io::Error

This commit may seem somewhat controversial at first, but hear me
out first. Currently, Yanix would return a custom error that's a
wrapper around three other error types returned by various entities
inside Rust's `libstd`. In particular, Yanix's error type would wrap
`io::Error`, `num::TryFromIntError` and `ffi::NulError`. It turns
out that there is a natural conversion between the first and the last
and provided by the standard library, i.e., `From<ffi::NulError> for io::Error`
is provided. So at the surface it may seem that only the first two
wrapped error types are worth keeping.

Digging a little bit deeper into `libstd`, `num::TryFromIntError`
is essentially speaking only a marker that the integral conversion
went wrong. The struct implementing this error stores a unit type,
and nothing more. It therefore seems like a waste to wrap this
particular error when we could unify everything under `io::Error`.
And so, whenever we perform an int conversion, I suggest we simply
remap the error to `io::Error::from_raw_os_error(libc::EOVERFLOW)`
since this carries a comparable amount of information.

As a result of completely discarding `yanix::Error` custom error type,
we are invariably simplifying `yanix` itself, but also allowing
`wasi-common` to simplify in several places as well.

* Adapt wasi-common to changes in yanix

* Add Cargo.lock

* Unwrap try_into's where possible

* Remove unnecessary type annotation
2020-03-06 14:20:54 -08:00
Jakub Konka
135a48ca7e wasi-common error cleanup: part 1, yanix (#1226)
* Reuse std::io::Error for raw *nix errno

This commit removes custom `yanix::Errno` and instead (as was
previously suggested) reuses `std::io::Error` to generate and wrap
raw *nix errno value.

* Update wasi-common to use new Yanix error type

This commit updates `wasi-common` to use new way of handling raw
OS error in `yanix`; i.e., via re-use of `std::io::Error` instead
of a custom `Errno` enum.

* Fix formatting

* Unwrap if io::Error created from raw OS error

This commit calls `unwrap` on `err` if that one was created via
`io::Error::last_os_error()`. It also refactors error matching
in several syscalls on the BSD platform (mainly).
2020-03-05 10:08:28 +01:00
Jakub Konka
4fe397ea43 Refactor and combine all FileType structs in yanix
This commit does a bit of everything: refactors bits here and there,
fixes a bug discovered in another #701, and combines all structs that
we used in `yanix` and `wasi-common` crates to represent file types
on *nix into one struct, `yanix::file::FileType`.

Up until now, in `yanix`, we've had two separate structs used to
represent file types on the host: `yanix::dir::FileType` and
`yanix::file::SFlags` (well, not quite, but that was its main use).
They both were used in different context (the former when parsing
`dirent` struct, and the latter when parsing `stat` struct), they
were C-compatible (as far as their representation goes), and as it
turns out, they shared possible enumeration values. This commit
combines them both into an idiomatic Rust enum with the caveat that
it is now *not* C-compatible, however, I couldn't find a single use
where that would actually matter, and even if it does in the future,
we can simply add appropriate impl methods.

The combine `yanix::file::FileType` struct can be constructed in two
ways: 1) either from `stat.st_mode` value (and while we're here,
now it's done correctly according to POSIX which fixes the bug mentioned
in VFS impl PR #701), or 2) from `dirent.d_type` value. Also, since we now
have one struct for representing both contexts, this cleans up nicely
a lot of duplicated code in `host` module.
2020-02-24 15:18:26 +01:00
Dan Gohman
c2ba419409 Misc yanix fixes (#715)
* Correctly handle possibly misaligned pointers in readdir

This reapplies #615, which was inadvertently reverted.

* Tidy up unneeded `self::` qualifiers.

* Make Dir's contents private.

Also remove the `unsafe` from `impl_iter`. With `Dir`'s field being
private, we can rely on the pointer being only what we've assigned to
it.

* Make `poll`'s timeout argument a `libc::c_int`.

This clarifies that there are no subsequent conversions before calling the
underlying libc API.

* Use clock_gettime instead of clock_getres to get the time.

* Mark FileType::from_raw as safe.

It handles unknown values, so it can be marked safe.
2019-12-16 13:34:22 -08:00
Jakub Konka
95c2addf15 Compile wasi-common to Emscripten (#688)
* Compile wasi-common to Emscripten

This commit enables cross-compiling of `wasi-common` to Emscripten. To achieve
this, this commit does quite a bit reshuffling in the existing codebase. Namely,
* rename `linux` modules in `wasi-common` and `yanix` to `linux_like` -- this is
  needed so that we can separate out logic specific to Linux and Emscripten out
* tweak `dir` module in `yanix` to support Emscripten -- in particular, the main
  change involves `SeekLoc::from_raw` which has to be now host-specific, and is now
  fallible
* tweak `filetime` so that in Emscripten we never check for existence of `utimensat`
  at runtime since we are guaranteed for it to exist by design
* since `utimes` and `futimes` are not present in Emscripten, move them into a separate
  module, `utimesat`, and tag it cfg-non-emscripten only
* finally, `to_timespec` is now fallible since on Emscripten we have to cast number of
  seconds, `FileTime::seconds` from `i64` to `libc::c_long` which resolves to `i32`
  unlike on other nixes

* Fix macos build

* Verify wasi-common compiles to Emscripten

This commit adds `emscripten` job to Github Actions which installs
`wasm32-unknown-emscripten` target, and builds `wasi-common` crate.

* Use #[path] to cherry-pick mods for Emscripten

This commit effectively reverses the reorg introduced in 145f4a5
in that it ditches `linux_like` mod for separate mods `linux` and
`emscripten` which are now on the same crate level, and instead,
pulls in common bits from `linux` using the `#[path = ..]` proc
macro.
2019-12-11 16:25:13 -08:00
Jakub Konka
51f880f625 Add yanix crate and replace nix with yanix in wasi-common (#649)
* Add yanix crate

This commit adds `yanix` crate as a Unix dependency for `wasi-common`.
`yanix` stands for Yet Another Nix crate and is exactly what the name
suggests: a crate in the spirit of the `nix` crate, but which takes a different
approach, using lower-level interfaces with less abstraction, so that it fits
better with its main use case, implementation of WASI syscalls.

* Replace nix with yanix crate

Having introduced `yanix` crate as an in-house replacement for the
`nix` crate, this commit makes the necessary changes to `wasi-common`
to depend _only_ on `yanix` crate.

* Address review comments

* make `fd_dup` unsafe
* rename `get_fd` to `get_fd_flags`, etc.
* reuse `io::Error::last_os_error()` to get the last errno value

* Address more comments

* make all `fcntl` fns unsafe
* adjust `wasi-common` impl appropriately

* Make all fns operating on RawFd unsafe

* Fix linux build

* Address more comments
2019-12-08 16:40:05 -08:00