Re: [PATCH -mm 4/10][RFC] aio: convert aio_complete to file_endio_t
From: David Brownell <hidden>
Date: 2007-01-16 05:53:46
Also in:
linux-fsdevel, lkml
On Monday 15 January 2007 5:54 pm, Nate Diller wrote:
quoted hunk ↗ jump to hunk
--- a/drivers/usb/gadget/inode.c 2007-01-12 14:42:29.000000000 -0800 +++ b/drivers/usb/gadget/inode.c 2007-01-12 14:25:34.000000000 -0800@@ -559,35 +559,32 @@ static int ep_aio_cancel(struct kiocb *i return value; } -static ssize_t ep_aio_read_retry(struct kiocb *iocb) +static int ep_aio_read_retry(struct kiocb *iocb) { struct kiocb_priv *priv = iocb->private; - ssize_t len, total; - int i; + ssize_t total; + int i, err = 0; /* we "retry" to get the right mm context for this: */ /* copy stuff into user buffers */ total = priv->actual; - len = 0; for (i=0; i < priv->nr_segs; i++) { ssize_t this = min((ssize_t)(priv->iv[i].iov_len), total); if (copy_to_user(priv->iv[i].iov_base, priv->buf, this)) { - if (len == 0) - len = -EFAULT; + err = -EFAULT;
Discarding the capability to report partial success, e.g. that the first N bytes were properly transferred? I don't see any virtue in that change. Quite the opposite in fact. I think you're also expecting that if N bytes were requested, that's always how many will be received. That's not true for packetized I/O such as USB isochronous transfers ... where it's quite legit (and in some cases routine) for the other end to send packets that are shorter than the maximum allowed. Sending a zero length packet is not the same as sending no packet at all, for another example.