On Thu, Jan 29, 2015 at 05:15:55AM +0000, Al Viro wrote:
> On Wed, Jan 28, 2015 at 06:11:02PM +0100, Christoph Hellwig wrote:
> > On Tue, Jan 27, 2015 at 04:54:22AM +0000, Al Viro wrote:
> > > I don't mind opening a never-rebased branch for generic iov_iter-related stuff;
> > > if you prefer to handle it that way - just tell. The first two patches
> > > from that series would definitely go there; as for the rest... no preferences
> > > here.
> >
> > It might make sense to just keep the VFS patches in your tree.
> > The target ones also are something I'd prefer if it goes through Nic
> > with additional review. In addition they aren't really critical,
> > so if you merge the prep patches now we can feed the rest through
> > the proper trees in the .21 merge window.
>
> Done. The first two are in #iov_iter now (merged into #for-next), the
> rest is dropped. And #iov_iter is in never-rebased mode, so feel free
> to pull it wherever you need it.
FWIW, there's an interesting question about the second commit in there -
what do we want vfs_iter_{read,write}() to do with *iter in case if it
has hit this:
if (ret == -EIOCBQUEUED)
ret = wait_on_sync_kiocb(&kiocb);
Do we require ->read_iter() and ->write_iter() on sync kiocb to do all
advancing the iter before returning -EIOCBQUEUED? What's more, do we
ever want to have it returned on sync kiocb? IOW, is there any point
in having that wait in callers?
Note that there are _very_ few drivers that ever do that; fs/direct_io.c,
for example, will wait for completion in case of sync kiocb. AFAICS,
there are exactly two drivers like that: drivers/usb/gadget/legacy/inode.c
and drivers/usb/gadget/function/f_fs.c. And the latter is very easy to
convert to "waits in case of sync kiocb" - there already are two codepaths
({read,write} and aio_{read,write}) and it's trivial to teach the sync
path to deal with arbitrary iov_iter, with aio side of things doing the
sync variant in case of sync kiocb. Cheaper, as well, since we don't need
to copy iovec, etc.
I'm not sure if ep_io() and ep_aio_rwtail() + wait for completion are
eqiuvalent; ep_read/ep_write are very easy to turn into sync side of
->read_iter/->write_iter and if that's equivalent to ep_aio_read/ep_aio_write
on sync kiocb + waiting for completion, we are fine.
Comments?
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
