From: Tejun Heo <htejun@gmail.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: tomof@acm.org, efault@gmx.de, jens.axboe@oracle.com,
James.Bottomley@HansenPartnership.com, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org,
linux-scsi@vger.kernel.org, jgarzik@pobox.com,
bzolnier@gmail.com
Subject: Re: [PATCH] block: fix residual byte count handling
Date: Wed, 05 Mar 2008 09:44:01 +0900 [thread overview]
Message-ID: <47CDECD1.6070601@gmail.com> (raw)
In-Reply-To: <20080305092619Y.fujita.tomonori@lab.ntt.co.jp>
Hello,
FUJITA Tomonori wrote:
> sglist is a low-level I/O representation for device drivers. SCSI
> midlayer should not care about sglist. We should not fix SCSI midlayer
> for rq->data_len != sum(sg) change (so I can't agree with your
> diagrams in another mail).
But that's not the way things currently are.
> When if we change a rule, we need to fix something.
>
> If we keep rq->data_len == sum(sg), we need to fix the device
> application layer. If we keep rq->data_len == the true data length, we
> need to fix the low-level drivers.
Basically everything under block layer.
> Now I'm fine with the commit e97a294ef6938512b655b1abf17656cf2b26f709
> since we are in -rc stages. But I plan to send a patch to revert it
> and fix this issue in the block layer. I'd like to test it in -mm for
> a while.
>
> Only sglist stuff in SCSI midlayer is scsi_req_map_sg now. As you
> know, we really want to remove it.
If the way forward is to make anything but the low level drivers not
care about sglist, in the long term, the current scheme is fine but I
still don't think this way of doing things is safe one. We're affecting
large portion of code based on what things should be in future not what
they currently are.
>> Things going the other way is fine with me but I at least want to hear a
>> valid rationale. Till now all I got is "because that's the true size"
>> which doesn't really make much sense to me.
>
> Most of users of request structure care about only the real data
> length, don't care about padding and drain length. Why do they bother
> to use a helper function to get the real data length?
I think this is where the difference comes from. To me it seems
internal usage seems more wide-spread and more delicate and not too many
care about the true size and when they do only in well defined places.
Maybe it comes from the difference between your most and my most.
Thanks.
--
tejun
next prev parent reply other threads:[~2008-03-05 0:44 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1203583379.6244.27.camel@homer.simson.net>
[not found] ` <20080222073228.GZ23197@kernel.dk>
[not found] ` <1203752563.5225.4.camel@homer.simson.net>
[not found] ` <1203839683.17463.9.camel@homer.simson.net>
[not found] ` <1204019283.8731.11.camel@homer.simson.net>
[not found] ` <1204033003.11828.22.camel@homer.simson.net>
2008-02-26 23:08 ` regression: CD burning (k3b) went broke Andrew Morton
2008-02-27 0:46 ` Jeff Garzik
2008-02-27 2:58 ` Mike Galbraith
2008-02-27 2:24 ` Mike Galbraith
2008-02-27 6:00 ` Mike Galbraith
2008-02-27 7:07 ` Mike Galbraith
2008-02-28 7:43 ` Tejun Heo
2008-02-28 8:20 ` Mike Galbraith
2008-02-28 8:50 ` [PATCH] block: fix residual byte count handling Tejun Heo
2008-02-28 15:35 ` Jens Axboe
2008-02-28 15:46 ` Tejun Heo
2008-02-29 16:47 ` James Bottomley
2008-02-29 20:11 ` Jens Axboe
2008-03-01 6:17 ` Tejun Heo
2008-03-01 15:19 ` James Bottomley
2008-03-02 14:52 ` FUJITA Tomonori
2008-03-02 18:46 ` Mike Christie
2008-03-03 3:27 ` Mike Galbraith
2008-03-03 2:40 ` Tejun Heo
2008-03-03 3:59 ` FUJITA Tomonori
2008-03-03 4:09 ` Tejun Heo
2008-03-03 6:08 ` [PATCH 1/2] " Tejun Heo
2008-03-03 6:10 ` [PATCH] block: separate out padding from alignment Tejun Heo
2008-03-03 18:27 ` James Bottomley
2008-03-03 8:26 ` [PATCH] block: fix residual byte count handling FUJITA Tomonori
2008-03-03 9:21 ` Tejun Heo
2008-03-03 12:17 ` FUJITA Tomonori
2008-03-03 13:38 ` Tejun Heo
2008-03-03 13:50 ` FUJITA Tomonori
2008-03-03 13:55 ` Tejun Heo
2008-03-03 14:01 ` FUJITA Tomonori
2008-03-03 14:22 ` Tejun Heo
2008-03-03 14:52 ` FUJITA Tomonori
2008-03-03 22:44 ` Tejun Heo
2008-03-04 2:11 ` FUJITA Tomonori
2008-03-04 2:32 ` Tejun Heo
2008-03-04 8:53 ` FUJITA Tomonori
2008-03-04 8:59 ` Jens Axboe
2008-03-04 9:06 ` FUJITA Tomonori
2008-03-04 9:22 ` FUJITA Tomonori
2008-03-04 9:30 ` Tejun Heo
2008-03-04 9:35 ` Jens Axboe
2008-03-04 9:40 ` Tejun Heo
2008-03-04 9:46 ` Jens Axboe
2008-03-04 12:37 ` Mike Galbraith
2008-03-04 12:39 ` Jens Axboe
2008-03-04 12:43 ` Mike Galbraith
2008-03-04 12:58 ` Mike Galbraith
2008-03-04 13:03 ` Jens Axboe
2008-03-04 14:25 ` Mike Galbraith
2008-03-04 18:17 ` Jens Axboe
2008-03-04 18:29 ` Jens Axboe
2008-03-04 18:35 ` Mike Galbraith
2008-03-04 18:45 ` Jens Axboe
2008-03-04 18:49 ` Mike Galbraith
2008-03-04 18:54 ` Jens Axboe
2008-03-04 19:26 ` Mike Galbraith
2008-03-04 19:28 ` Jens Axboe
2008-03-04 16:04 ` James Bottomley
2008-03-04 18:46 ` Jens Axboe
2008-03-04 17:34 ` walt
2008-03-04 17:59 ` Tejun Heo
2008-03-04 19:18 ` walt
2008-03-04 19:42 ` Kiyoshi Ueda
2008-03-04 12:40 ` Tejun Heo
2008-03-04 12:45 ` Mike Galbraith
2008-03-04 13:30 ` FUJITA Tomonori
2008-03-04 13:50 ` Tejun Heo
2008-03-04 16:17 ` Tejun Heo
2008-03-04 16:42 ` Tejun Heo
2008-03-04 18:26 ` Boaz Harrosh
2008-03-04 18:35 ` Tejun Heo
2008-03-04 18:27 ` James Bottomley
2008-03-04 18:33 ` Tejun Heo
2008-03-04 18:45 ` Mike Galbraith
2008-03-04 19:25 ` Jens Axboe
2008-03-04 19:33 ` Mike Galbraith
2008-03-04 19:34 ` Jens Axboe
2008-03-04 19:19 ` FUJITA Tomonori
2008-03-04 23:33 ` Tejun Heo
2008-03-04 23:54 ` Tejun Heo
2008-03-05 0:26 ` FUJITA Tomonori
2008-03-05 0:44 ` Tejun Heo [this message]
2008-03-06 4:56 ` FUJITA Tomonori
2008-03-06 5:02 ` Tejun Heo
2008-03-05 10:16 ` [PATCH] blk: missing add of padded bytes to io completion byte count Boaz Harrosh
2008-03-05 12:28 ` Mike Galbraith
2008-03-05 12:33 ` Jens Axboe
2008-03-05 12:46 ` Boaz Harrosh
2008-03-05 12:48 ` Jens Axboe
2008-03-05 13:45 ` Tejun Heo
2008-03-05 13:51 ` Jens Axboe
2008-03-05 14:08 ` Tejun Heo
2008-03-05 15:21 ` James Bottomley
2008-03-06 4:41 ` FUJITA Tomonori
2008-03-06 13:41 ` Jens Axboe
2008-03-07 0:07 ` Tejun Heo
2008-03-07 15:07 ` FUJITA Tomonori
2008-03-08 1:06 ` Tejun Heo
2008-03-20 12:54 ` FUJITA Tomonori
2008-03-05 14:46 ` Boaz Harrosh
2008-03-05 15:11 ` Tejun Heo
2008-03-06 5:02 ` FUJITA Tomonori
2008-03-04 9:29 ` [PATCH] block: fix residual byte count handling Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47CDECD1.6070601@gmail.com \
--to=htejun@gmail.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=akpm@linux-foundation.org \
--cc=bzolnier@gmail.com \
--cc=efault@gmx.de \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=jens.axboe@oracle.com \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=tomof@acm.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).