On Thu, 2008-11-27 at 18:53 +0900, FUJITA Tomonori wrote:
> > + blk_end_bidi_request(job->req, err, blk_rq_bytes(job->req), bytes_requested);
> >
> > The residual count is left in req->data_len. Does bsg have a way to return the
> > residual to user-mode? It must, since Pete was using that for sure. Note that
> > you are looking for the bidi_read residual count.
>
> Yeah, bsg has. struct sg_io_v4 has:
>
> __s32 din_resid; /* [o] din_xfer_len - actual_din_xfer_len */
> __s32 dout_resid; /* [o] dout_xfer_len - actual_dout_xfer_len */
>
>
> > As was said by people. You must complete ALL bytes on both sides. Residual information
> > is passed through req->data_len. Other wise the request is still active.
> >
> > (And yes blk_end_request uses blk_end_bidi_request internally)
>
> We always complete all bytes on both sides. So why we do something
> like:
>
> int blk_end_request(struct request *rq, int error, unsigned int nr_bytes)
> {
> unsigned int bidi_bytes = 0;
>
> if (blk_bidi_rq(rq))
> bidi_bytes = req->next_rq->data_len;
>
> return blk_end_io(rq, error, nr_bytes, bidi_bytes, NULL);
> }
That looks good ... care to patch it up (including conversion of all the
users) and send it to Jens for consideration?
> The callers can do something like:
>
> blk_end_request(rq, err, rq->data_len);
> rq-->next_rq->data_len = resid;
Um ... I see what you're trying to do, but I don't think it works like
this. The residual could be collected in the end_io call back which is
inline in the blk_end_request().
James
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
