Generalise read and write.

[wedsonaf]

This is also in preparation for adding support for read_iter and
write_iter.

An extra argument is being added to write for consistency with the
other functions.

Otherwise, this is a pure refactor.

Based on #229.

Signed-off-by: Wedson Almeida Filho [email protected]

[alex]

One more for rebasing :-)

[wedsonaf]

One more for rebasing :-)

Done. Thanks for the reviews :)

[alex]

Can you explain more about the motivation for this? I read the read_iter PR but it doesn't look like it depends on this.

[wedsonaf]

Can you explain more about the motivation for this? I read the read_iter PR but it doesn't look like it depends on this.

read_iter and write_iter depend on this.

The idea is that someone writing a driver provides a single implementation of read and write: given that they are generalised on any IoBufferWriter and IoBufferReader, read_iter_callback and writer_iter_callback call the very same read and write called by read_callback and write_callback (only using a different instantiation, IovIterX vs UserSlicePtrX).

IOW, a driver gets read_iter and write_iter for free once it has read and write. See for example read_iter_zero and read_zero here https://elixir.bootlin.com/linux/latest/source/drivers/char/mem.c#L699 -- in C, they need to implement two functions that do the same thing but that deal with char __user * and struct iov_iter; in Rust they only need one.

[alex]

Is it always desired to use the same implementation for read and read_iter? I'm imagining maybe doing smart things like processing one iov at a time?

…

On Tue, Apr 27, 2021 at 5:31 PM Wedson Almeida Filho < ***@***.***> wrote: Can you explain more about the motivation for this? I read the read_iter PR but it doesn't look like it depends on this. read_iter and write_iter depend on this. The idea is that someone writing a driver provides a single implementation of read and write: given that they are generalised on any IoBufferWriter and IoBufferReader, read_iter_callback and writer_iter_callback call the very some read and write called by read_callback and write_callback (only using a different instantiation, IovIterX vs UserSlicePtrX). IOW, a driver gets read_iter and write_iter for free once it has read and writer. See for example read_iter_zero and read_zero here https://elixir.bootlin.com/linux/latest/source/drivers/char/mem.c#L699 -- in C, they need to implement two functions that do the same thing but that deal with char __user * and struct iov_iter; in Rust they only need one. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#230 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBHVHTEWR4TTG33V2VDTK4UMHANCNFSM43VIS7ZA> .

-- All that is necessary for evil to succeed is for good people to do nothing.

[wedsonaf]

Is it always desired to use the same implementation for read and read_iter? I'm imagining maybe doing smart things like processing one iov at a time?

Let's suppose a developer wants to do something smart with iovs. We can expose more information to them via IoBufferX that allows them to do so; the non-iter case would be a degenerate case with only one iov, and would optimise away any loops. We still benefit from a single implementation. (Though instead of both being 'dumb', they're both 'smart'.)

My initial inclination was to remove read and write altogether. A quick experiment with dd shows that read is faster than read_iter though, so I thought I'd keep both for now at least. In the future, if read_iter improves we always have the option to drop read; the existence of both seems like an artefact of the kernel evolution -- see for example this comment from who I believe is Al Viro saying "I very much hope to get rid of the piles of read/write methods."