From: Boaz Harrosh <bharrosh@panasas.com>
To: Jens Axboe <axboe@kernel.dk>,
James Bottomley <James.Bottomley@SteelEye.com>,
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-ide@vger.kernel.org, dm-devel@redhat.com,
j-nomura@ce.jp.nec.com
Subject: Re: [PATCH 00/28] blk_end_request: full I/O completion handler (take 3)
Date: Tue, 04 Dec 2007 16:09:28 +0200 [thread overview]
Message-ID: <47555F98.8030504@panasas.com> (raw)
In-Reply-To: <20071204121623.GQ23294@kernel.dk>
On Tue, Dec 04 2007 at 14:16 +0200, Jens Axboe <axboe@kernel.dk> wrote:
> On Fri, Nov 30 2007, Kiyoshi Ueda wrote:
>> Hello Jens,
>>
>> The following is the updated patch-set for blk_end_request().
>> Changes since the last version are only minor updates to catch up
>> with the base kernel changes.
>> Do you agree the implementation of blk_end_request()?
>> If there's no problem, could you merge it to your tree?
>> Or does it have to be merged to -mm tree first?
>>
>>
>> Boaz,
>> Could you review the newly added PATCH 27 which converts the bidi part,
>> and give me your comments?
>> It uses blk_end_request_callback() in PATCH 25, which was only for
>> the tricky ide-cd driver.
>> If bidi added a 'resid' member to struct request instead of reusing
>> 'data_len' for the other purpose, it could use the standard
>> blk_end_request() instead.
>>
>> ------------------ Changes from the previous post ---------------------
>> Changes between take2 and take3:
>> o Rebased on top of 2.6.24-rc3-mm2
>
> OK, so this means that I can't apply it unfortunately. It depends on
> other patches in -mm (bidi).
>
> SCSI sits on block, so the best approach imho is to base this patchset
> on mainline so I can include the block bits.
>
>
I was wishing that the bidi work can go into 2.6.25, I guess that's
James to say. If so than it is not important what order they go in.
Or the patchset can be submitted in two parts, with scsi and remove-of-
old-API in a later stage.
Or *rant* Boaz can just rebase his work again *rant*.
Kiyoshi, It's OK, if you have a maintainer that is willing to
accept your work then go head, My code can wait, no problem.
Just resolve the resid issue in scsi_io_completion()
(See my other mail)
Thanks for doing this
Boaz
prev parent reply other threads:[~2007-12-04 14:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-30 23:23 [PATCH 00/28] blk_end_request: full I/O completion handler (take 3) Kiyoshi Ueda
2007-11-30 23:23 ` Kiyoshi Ueda
2007-12-04 12:06 ` Jens Axboe
2007-12-04 12:16 ` Jens Axboe
2007-12-04 14:09 ` Boaz Harrosh [this message]
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=47555F98.8030504@panasas.com \
--to=bharrosh@panasas.com \
--cc=James.Bottomley@SteelEye.com \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=j-nomura@ce.jp.nec.com \
--cc=k-ueda@ct.jp.nec.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.