linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
To: jens.axboe@oracle.com
Cc: bzolnier@gmail.com, fujita.tomonori@lab.ntt.co.jp,
	linux-ide@vger.kernel.org, petkovbb@gmail.com
Subject: Re: [PATCH v2 00/13] removing the on-stack struct request
Date: Tue, 6 May 2008 11:39:52 +0900	[thread overview]
Message-ID: <20080506113953H.tomof@acm.org> (raw)
In-Reply-To: <20080505190409.GB329@kernel.dk>

On Mon, 5 May 2008 21:04:09 +0200
Jens Axboe <jens.axboe@oracle.com> wrote:

> On Mon, May 05 2008, Bartlomiej Zolnierkiewicz wrote:
> > On Monday 05 May 2008, FUJITA Tomonori wrote:
> > > On Sat, 3 May 2008 15:10:02 +0200
> > > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> > > 
> > > > 
> > > > Hi,
> > > > 
> > > > On Thursday 01 May 2008, FUJITA Tomonori wrote:
> > > > > This is an updated version of the patchset to clean up the asymmetry
> > > > > of blk_get/put_request usage:
> > > > > 
> > > > > http://marc.info/?l=linux-ide&m=120882410712466&w=2
> > > > > 
> > > > > This patchset removes the code calling blk_put_request against the
> > > > > requests that are not allocated via blk_get_request. They can use
> > > > > __GFP_WAIT allocation so we can easily convert them to
> > > > > use blk_get/put_request properly.
> > > > > 
> > > > > This patchset enables us to remove the following hack in
> > > > > blk_put_request:
> > > > > 
> > > > > /*
> > > > >  * Gee, IDE calls in w/ NULL q.  Fix IDE and remove the
> > > > >  * following if (q) test.
> > > > >  */
> > > > > if (q) {
> > > > > 	spin_lock_irqsave(q->queue_lock, flags);
> > > > > 	__blk_put_request(q, req);
> > > > > 	spin_unlock_irqrestore(q->queue_lock, flags);
> > > > > }
> > > > > 
> > > > > The major changes are:
> > > > > 
> > > > > - I remove the ide_wait/head_wait path in ide_do_drive_cmd(). It does
> > > > > the same thing that blk_execute_rq() does. So let's simply use
> > > > > blk_execute_rq(). The nice side effect is that I unexport
> > > > > blk_end_sync_rq() since I converted all the users.
> > > > > 
> > > > > - I drop the unnecessary patch to make ide_do_drive_cmd return
> > > > > rq->errors:
> > > > > 
> > > > > http://marc.info/?l=linux-ide&m=120882410612456&w=2
> > > > > 
> > > > > #1-10 are for the ide subsystem and #11-13 for the block layer. This
> > > > > is against the lastest Linus tree.
> > > > 
> > > > Thanks.
> > > > 
> > > > I applied patches #1-10 after making ide_do_drive_cmd() more similar to
> > > > blk_execute_rq() (to ease the conversion - it is really better to handle
> > > > subtle changes first). [ I'll send these pre-patches in separate mails. ]
> > > 
> > > Thanks for applying the patches.
> > > 
> > > 
> > > > However I'm still not quite sure about following change in patch #1:
> > > > 
> > > > @@ -456,24 +452,21 @@ int ide_cdrom_packet(struct cdrom_device_info *cdi,
> > > > ...
> > > > -	cgc->stat = ide_cd_queue_pc(drive, &req);
> > > > +	cgc->stat = ide_cd_queue_pc(drive, cgc->cmd,
> > > > +				    cgc->data_direction == CGC_DATA_WRITE,
> > > > +				    cgc->buffer, cgc->buflen,
> > > > +				    cgc->sense, cgc->timeout, flags);
> > > >  	if (!cgc->stat)
> > > > -		cgc->buflen -= req.data_len;
> > > > +		cgc->buflen = 0;
> > > > ...
> > > > 
> > > > IIRC rq->data_len may be modified while the request is processed?
> > > 
> > > I think that rq->data_len is modified only when a request is
> > > successful but I might overlook or misunderstand something. How about
> > > the attached patch (against the latest your quilt patchset)? It's a
> > > bit hacky but it should work as before.
> > > 
> > > 
> > > > [ The only other (minor) complaint is that patches #9-10 should be at the
> > > >   beginning of the patch series but since no patches contained problems it
> > > >   wouldn't be wise to ask respin just for that (and I'm too lazy to review
> > > >   it all again ;-). ]
> > > 
> > > Thanks.
> > > 
> > > If you are ok with the attached patch, I'm happy to incorporate it
> > > into the patchset and send a new version as you like.
> > > 
> > > 
> > > ==
> > > From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> > > Subject: ide: let ide_cd_queue_pc return rq->data_len
> > > 
> > > ide_cdrom_packet needs rq->data_len after the completion so this patch
> > > makes ide_cd_queue_pc return rq->data_len.
> > > 
> > > Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> > 
> > Thanks!  I just integrated this change with patch #1 so there is no need
> > for you to repost the whole patchset.

Thanks a lot!


> > WRT patches #11-13: since they are quite straightforward I wonder whether
> > it might make sense to push them through IDE tree (they depend on #1-10)?
> > 
> > Jens, if you are fine with it I'll add your SOB and add them to the queue.
> 
> Since they are so small, not an issue with me. You may add my
> Signed-off-by, I'm glad that we are (finally) getting rid of the
> on-stack requests.

Yeah, the remaining on-stack requests are used in the paths that we
can't fail to allocate the requests (e.g. from interrupt
context). They are legitimate, as discussed before. We got rid of the
asymmetry of blk_get_request and blk_put_request usage in IDE and the
hack in blk_put_request so I'm glad too.

Thanks,

  reply	other threads:[~2008-05-06  2:40 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-01 12:27 [PATCH v2 00/13] removing the on-stack struct request FUJITA Tomonori
2008-05-01 12:27 ` [PATCH v2 01/13] ide-cd: convert ide_cd_queue_pc to use blk_execute_rq FUJITA Tomonori
2008-05-01 12:27   ` [PATCH v2 02/13] ide-cd: convert ide_do_drive_cmd path " FUJITA Tomonori
2008-05-01 12:28     ` [PATCH v2 03/13] ide-disk: " FUJITA Tomonori
2008-05-01 12:28       ` [PATCH v2 04/13] ide-floppy: " FUJITA Tomonori
2008-05-01 12:28         ` [PATCH v2 05/13] ide-taskfile: " FUJITA Tomonori
2008-05-01 12:28           ` [PATCH v2 06/13] ide-tape: " FUJITA Tomonori
2008-05-01 12:28             ` [PATCH v2 07/13] ide: " FUJITA Tomonori
2008-05-01 12:28               ` [PATCH v2 08/13] ide: remove ide_wait/head_wait path in ide_do_drive_cmd FUJITA Tomonori
2008-05-01 12:28                 ` [PATCH v2 09/13] ide: remove ide_init_drive_cmd FUJITA Tomonori
2008-05-01 12:28                   ` [PATCH v2 10/13] ide-cd: remove ide_cd_init_rq FUJITA Tomonori
2008-05-01 12:28                     ` [PATCH v2 11/13] block: convert pd_special_command to use blk_execute_rq FUJITA Tomonori
2008-05-01 12:28                       ` [PATCH v2 12/13] block: remove the checking for NULL queue in blk_put_request FUJITA Tomonori
2008-05-01 12:28                         ` [PATCH v2 13/13] block: unexport blk_end_sync_rq FUJITA Tomonori
2008-05-02 14:04 ` [PATCH v2 00/13] removing the on-stack struct request Borislav Petkov
2008-05-02 16:13   ` FUJITA Tomonori
2008-05-03 13:10 ` Bartlomiej Zolnierkiewicz
2008-05-05 13:02   ` FUJITA Tomonori
2008-05-05 16:49     ` Bartlomiej Zolnierkiewicz
2008-05-05 19:04       ` Jens Axboe
2008-05-06  2:39         ` FUJITA Tomonori [this message]
2008-05-06 16:18           ` Bartlomiej Zolnierkiewicz

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=20080506113953H.tomof@acm.org \
    --to=fujita.tomonori@lab.ntt.co.jp \
    --cc=bzolnier@gmail.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=petkovbb@gmail.com \
    /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).