From: Tejun Heo <htejun@gmail.com>
To: James Bottomley <James.Bottomley@SteelEye.com>,
Jens Axboe <axboe@suse.de>,
SCSI Mailing List <linux-scsi@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: Regarding posted scsi midlyaer patchsets
Date: Mon, 18 Apr 2005 23:58:46 +0900 [thread overview]
Message-ID: <4263CB26.2070609@gmail.com> (raw)
In-Reply-To: <1113833744.4998.13.camel@mulgrave>
Hello, James.
Hello, Jens.
James Bottomley wrote:
> On Mon, 2005-04-18 at 07:41 +0900, Tejun Heo wrote:
>
>> As it's been almost a week since I posted scsi midlayer patchsets and
>>haven't heard anything yet, I've been wondering what's going on. Are
>>they under review or all dropped? If they are dropped, can you please
>>tell me why they are dropped?
>
>
> I have about four of them in the scsi-misc-2.6 tree, if you look.
>
> Your request path rewrite I already gave you feedback that I didn't want
> REQ_SOFTBARRIER in scsi ... it needs to be in the block submit API for
> special requests. Also, you have a patch for block in this code so I
> can't apply it without an ack from Jens. And all the rest of your
> patches depend on this one.
This thread started as an private inquiry to James regarding the status
of four patchsets I posted about a week ago. I'm replying publicly as I
think we can use some discussion. The four patchsets are... (in the
following order)
* timer updates
* REQ_SPECIAL/REQ_SOFTBARRIER usage change
* scsi_request_fn reimpl
* requeue path consolidation.
Accepted patches are
* scsi_cmnd->internal_timeout kill
* scsi_cmnd->serial_number_at_timeout
* remove volatile
* scsi_send_eh_cmnd() clean up
All four accepted patches are not included in any of above patchsets
and the timer update patchset doesn't depend on
REQ_SPECIAL/REQ_SOFTBARRIER usage change patchset, so please review the
timer update patchset.
And, James, regarding REQ_SOFTBARRIER, if the REQ_SOFTBARRIER thing can
be removed from SCSI midlayer, do you agree to change REQ_SPECIAL to
mean special requests? If so, I have three proposals.
* move REQ_SOFTBARRIER setting to right after the allocation of
scsi_cmnd in scsi_prep_fn(). This will be the only place where
REQ_SOFTBARRIER is used in SCSI midlayer, making it less pervasive.
* Or, make another API which sets REQ_SOFTBARRIER on requeue. maybe
blk_requeue_ordered_request()?
* Or, make blk_insert_request() not set REQ_SPECIAL on requeue. IMHO,
this is a bit too subtle.
I like #1 or #2. Jens, what do you think? Do you agree to remove
requeue feature from blk_insert_request()?
Thanks a lot. :-)
--
tejun
next parent reply other threads:[~2005-04-18 14:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20050417224101.GA2344@htj.dyndns.org>
[not found] ` <1113833744.4998.13.camel@mulgrave>
2005-04-18 14:58 ` Tejun Heo [this message]
2005-04-19 12:34 ` Regarding posted scsi midlyaer patchsets Jens Axboe
2005-04-19 14:18 ` James Bottomley
2005-04-19 14:30 ` Jens Axboe
2005-04-19 14:33 ` Jens Axboe
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=4263CB26.2070609@gmail.com \
--to=htejun@gmail.com \
--cc=James.Bottomley@SteelEye.com \
--cc=axboe@suse.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox