On Thu, Apr 30, 2009 at 10:59:10AM +0900, Tejun Heo wrote: > Hello, James. > > James Bottomley wrote: > > This looks good (although I'd like to test it first). > > Yeah, this will need quite a bit of testing. > > > Might it not be better to have an accessor setting resid_len? All > > the other patches in the series insulate users from the actual > > members of struct request by accessors, so this is a bit the odd man > > out. > > I actually think it's better to expose resid_len in this case as the > semantics of the field is - initialized to zero on issue, contains > residual count on completion and whatever it contains inbetween is > upto the low level driver. Request position or length are different > as they must contain well defined values throughout request processing > and both block layer and low level driver should agree on what they > mean. > > Fancy words aside, it basically boils down to allowing llds to do > either "rq->resid_len = blk_rq_bytes() - xferred" on completion or > "rq->resid_len = blk_rq_bytes()" on issue and "rq->resid_len -= > increments" while processing. Actually, the second one sounds more natural: resid_len == data_len on issue and decrementing while travelling through block layer and LLDD, while resid_len == 0 in issue might get confused somewhere. And I like it too, we've been coming up with all sorts of hacks in ide-atapi wrt to residual completion and accounting of what got xferred already and rq->resid_len is much more cleaner, IMHO. /me testing... -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html