Re: [PATCH 1/5] rust: iov: add iov_iter abstractions for ITER_SOURCE

Alice Ryhl
2025-03-19T12:08:46Z

On Tue, Mar 18, 2025 at 09:10:47PM +0100, Christian Schrefl wrote:
> Hi Alice
>
> On 11.03.25 3:25 PM, Alice Ryhl wrote:
> > This adds abstractions for the iov_iter type in the case where
> > data_source is ITER_SOURCE. This will make Rust implementations of
> > fops->write_iter possible.
> >
> > This series only has support for using existing IO vectors created by C
> > code. Additional abstractions will be needed to support the creation of
> > IO vectors in Rust code.
> >
> > These abstractions make the assumption that `struct iov_iter` does not
> > have internal self-references, which implies that it is valid to move it
> > between different local variables, and that you can make a copy of it to
> > get two IO vectors into the same buffers.
>
> Would it make sense to add comments in the C side `struct iov_iter` for
> these assumptions?

Good idea.

> > + /// Returns the number of bytes available in this IO vector.
> > + ///
> > + /// Note that this may overestimate the number of bytes. For example, reading from userspace
> > + /// memory could fail with EFAULT, which will be treated as the end of the IO vector.
> > + #[inline]
> > + pub fn len(&self) -> usize {
> > + // SAFETY: It is safe to access the `count` field.
> > + unsafe {
> > + (*self.iov.get())
> > + .__bindgen_anon_1
> > + .__bindgen_anon_1
> > + .as_ref()
> > + .count
> > + }
> > + }
>
> Maybe add a C helper to avoid having to use '__bindgen_anon_1'?

I guess I could do that. Though it introduces a mandatory function call
that can't be inlined to get the length.

Alice