unix: add support for libc::readv and libc::writev

[mstoeckl]

readv and writev are vectored versions of read/write which are included in POSIX. (See e.g. man 3p readv, writev .) They could be (and sometimes have been) implemented using a loop and many read or write calls, so their semantics are not unusual.

I was advised to make this issue by the following error message:

test test ... error: unsupported operation: can't call foreign function `readv` on OS `linux`
   --> src/test.rs:125:19
    |
125 |         let ret = libc::readv(src_fd.as_raw_fd(), iovs.as_ptr(), iovs.len() as _);
    |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't call foreign function `readv` on OS `linux`
    |
    = help: if this is a basic API commonly used on this target, please report an issue with Miri
    = help: however, note that Miri does not aim to support every FFI function out there; for instance, we will not support APIs for things such as GUIs, scripting languages, or databases

A workaround for this error: under cfg(miri), replace libc::readv/libc::writev with functions that implement them using libc::read/libc::write directly.

[shamb0]

Hi @RalfJung, I am interested to work on this issue, Could you please assign this task to me.

[RalfJung]

@shamb0 you can do that yourself. :) Just write @rustbot claim.

[shamb0]

@shamb0 you can do that yourself. :) Just write @rustbot claim.

Thanks @RalfJung

[shamb0]

@rustbot claim

[RalfJung]

They could be (and sometimes have been) implemented using a loop and many read or write calls,

That does not seem right. The docs say that the entire readv call is atomic in terms of the file contents it observes. So implementing them as a loop will not behave correctly.

[mstoeckl]

That does not seem right.

Good point, I was wrong there. Double checking man 2 readv, I see that a temporary buffer was used instead:

In the case of readv(), the wrapper function allocated temporary buffer large enough for all of the items specified by iov, that buffer in a call to read(2), copied data from the buffer to the specified by the iov_base fields of the elements of iov, and then the buffer. The wrapper function for writev() performed the analogous using a temporary buffer and a call to write(2).

[RalfJung]

@rustbot release-assignment
(based on #4110 (comment))

[RalfJung]

What we learned from the first attempt here is that some more preparation is needed: read (and write, but please just do read in the first PR so iteration is easier) in trait FileDescription need to be adjusted to support customizing what happens after the operation is complete. Specifically, the dest: &MPlaceTy<'tcx> argument should be replaced by a finish: DynMachineCallback<Result<u64, IoError>>. The existing read/write shims should then implement finish as "write to dest, maybe update errno".

This will require changes to all existing FileDescription instances, but should otherwise not require any new logic.