[lkml]   [2009]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 03/10] block: add rq->resid_len
On Wed, 2009-04-29 at 18:13 +0900, Tejun Heo wrote:
> rq->data_len served two purposes - the length of data buffer on issue
> and the residual count on completion. This duality creates some
> headaches.
> First of all, block layer and low level drivers can't really determine
> what rq->data_len contains while a request is executing. It could be
> the total request length or it coulde be anything else one of the
> lower layers is using to keep track of residual count. This
> complicates things because blk_rq_bytes() and thus
> [__]blk_end_request_all() relies on rq->data_len for PC commands.
> Drivers which want to report residual count should first cache the
> total request length, update rq->data_len and then complete the
> request with the cached data length.
> Secondly, it makes requests default to reporting full residual count,
> ie. reporting that no data transfer occurred. The residual count is
> an exception not the norm; however, the driver should clear
> rq->data_len to zero to signify the normal cases while leaving it
> alone means no data transfer occurred at all. This reverse default
> behavior complicates code unnecessarily and renders block PC on some
> drivers (ide-tape/floppy) unuseable.
> This patch adds rq->resid_len which is used only for residual count.
> While at it, remove now unnecessasry blk_rq_bytes() caching in
> ide_pc_intr() as rq->data_len is not changed anymore.
> [ Impact: cleanup residual count handling, report 0 resid by default ]

This looks good (although I'd like to test it first).

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.


 \ /
  Last update: 2009-04-29 16:45    [W:0.110 / U:11.276 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site