lkml.org 
[lkml]   [2009]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 08/10] block: cleanup rq->data_len usages
James Bottomley wrote:
> On Thu, 2009-04-30 at 16:47 +0300, Boaz Harrosh wrote:
>>> @@ -966,7 +965,7 @@ static int scsi_init_sgtable(struct request
>> *req, struct scsi_data_buffer *sdb,
>>> BUG_ON(count > sdb->table.nents);
>>> sdb->table.nents = count;
>>> if (blk_pc_request(req))
>>> - sdb->length = req->data_len;
>>> + sdb->length = blk_rq_bytes(req);
>>> else
>>> sdb->length = blk_rq_sectors(req) << 9;
>> Is this true. I thought they must be the same now. I was actually
>> anticipating this if() removed.
>
> Me too ... there's one of these in scsi_lib.c as well.

Not until the next patch. It's probably safe for scsi to make the
switch here but I wanted to do the transition in two logical steps -
1. make all users use accessors in the defined manner without
affecting anything else 2. knowing #1 is true for all low level
drivers, unify implementation inside block layer. I had a following
patch which tried to do sweep conversion of all llds (which is
guaranteed to be safe after #2 has happened) but it looked like more
trouble than worth and seems like best left to each subsystem, so
please go ahead and clean up subsystems on top of this patchset. :-)

> The difference comes because filesystem requests are always in sectors,
> but BLOCK_PC requests are always in bytes .... we should be able to wrap
> the accessors so they do the correct conversions.

After this series is applied, blk_rq_bytes() >> 9 == blk_rq_sectors()
is guaranteed (note that blk_rq_sectors() << 9 might not equal
blk_rq_bytes() if the data transfer length isn't multiple of 512), so
the above if can be removed. I just didn't want to make the
conversion (probably safe for scsi) before the actual unification.

Thanks.

--
tejun


\
 
 \ /
  Last update: 2009-05-03 03:37    [W:1.213 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site