All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: jens.axboe@oracle.com, linux-scsi@vger.kernel.org,
	James.Bottomley@HansenPartnership.com
Subject: Re: [PATCH] block: integrate blk_end_bidi_request into blk_end_request
Date: Sun, 30 Nov 2008 13:10:31 +0200	[thread overview]
Message-ID: <493274A7.5050404@panasas.com> (raw)
In-Reply-To: <20081128145221I.fujita.tomonori@lab.ntt.co.jp>

FUJITA Tomonori wrote:
> Hi Jens,
> 
> FC people have been working on FC pass thru feature using bsg bidi
> support. Seems that the bidi API confuse them:
> 
> http://marc.info/?l=linux-scsi&m=122704347209856&w=2
> 
> =
> From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> [PATCH] block: integrate blk_end_bidi_request with blk_end_request
> 
> This integrates blk_end_bidi_request into blk_end_request. IOW, it
> changes blk_end_request to handle both bidi and non-bidi requests and
> removes blk_end_bidi_request.
> 
> Currently, we have two functions to complete a request,
> blk_end_bidi_request and blk_end_request. The former is for bidi
> requests and the latter is for non-bidi. This seems to confuse
> developers. Questions like "can blk_end_bidi_request be used with
> non-bidi requests?", "what should be passed as the bidi_bytes argument
> in blk_end_bidi_request" are often asked.
> 
> The callers don't care about whether a request is bidi or not. All
> they want to do is to complete a request. I think that a single
> function that can complete any request would be easy to understand.
> 
> We always must complete all bytes on both sides with bidi. So
> blk_end_request easily can do it for the callers and handle both both
> bidi and non-bidi requests.
> 
> 
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>

NACK by Boaz Harrosh.

> ---
>  block/blk-core.c        |   35 +++++++++++++----------------------
>  drivers/scsi/scsi_lib.c |    3 +--
>  include/linux/blkdev.h  |    2 --
>  3 files changed, 14 insertions(+), 26 deletions(-)
> 
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 10e8a64..634f918 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -1943,7 +1943,19 @@ static int blk_end_io(struct request *rq, int error, unsigned int nr_bytes,
>   **/
>  int blk_end_request(struct request *rq, int error, unsigned int nr_bytes)
>  {
> -	return blk_end_io(rq, error, nr_bytes, 0, NULL);
> + 	unsigned int bidi_bytes	= 0;
> +
> +	if (blk_bidi_rq(rq)) {
> +		struct bio *bio;
> +		/*
> +		 * We can't use rq->next_rq->data_len here because the
> +		 * callers might set it to a residual length.
> +		 */
> +		__rq_for_each_bio(bio, rq->next_rq)
> +			bidi_bytes += bio->bi_size;

No. I do not want a loop to calculate the size here. This is ugly.
I have this information, and I just lost it do to BAD API.

Since we do not want to change all users of blk_end_request. (We should,
but we are too lazy. I'm). Then please just let blk_end_bidi_request()
be. Confused users will be corrected.

Perhaps we can put a comment above blk_end_bidi_request() that it can
be used for both bidi or uni commands, so users will confuse less.

> +	}
> +
> +	return blk_end_io(rq, error, nr_bytes, bidi_bytes, NULL);
>  }
>  EXPORT_SYMBOL_GPL(blk_end_request);
>  
> @@ -1974,27 +1986,6 @@ int __blk_end_request(struct request *rq, int error, unsigned int nr_bytes)
>  EXPORT_SYMBOL_GPL(__blk_end_request);
>  
>  /**
> - * blk_end_bidi_request - Helper function for drivers to complete bidi request.
> - * @rq:         the bidi request being processed
> - * @error:      %0 for success, < %0 for error
> - * @nr_bytes:   number of bytes to complete @rq
> - * @bidi_bytes: number of bytes to complete @rq->next_rq
> - *
> - * Description:
> - *     Ends I/O on a number of bytes attached to @rq and @rq->next_rq.
> - *
> - * Return:
> - *     %0 - we are done with this request
> - *     %1 - still buffers pending for this request
> - **/
> -int blk_end_bidi_request(struct request *rq, int error, unsigned int nr_bytes,
> -			 unsigned int bidi_bytes)
> -{
> -	return blk_end_io(rq, error, nr_bytes, bidi_bytes, NULL);
> -}
> -EXPORT_SYMBOL_GPL(blk_end_bidi_request);
> -
> -/**
>   * blk_update_request - Special helper function for request stacking drivers
>   * @rq:           the request being processed
>   * @error:        %0 for success, < %0 for error
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index f5d3b96..e550e3b 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -842,13 +842,12 @@ static void scsi_end_bidi_request(struct scsi_cmnd *cmd)
>  {
>  	struct request *req = cmd->request;
>  	unsigned int dlen = req->data_len;
> -	unsigned int next_dlen = req->next_rq->data_len;
>  
>  	req->data_len = scsi_out(cmd)->resid;
>  	req->next_rq->data_len = scsi_in(cmd)->resid;
>  
>  	/* The req and req->next_rq have not been completed */
> -	BUG_ON(blk_end_bidi_request(req, 0, dlen, next_dlen));
> +	BUG_ON(blk_end_request(req, 0, dlen));
>  
>  	scsi_release_buffers(cmd);
>  
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index a135256..2a22755 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -799,8 +799,6 @@ extern int blk_end_request(struct request *rq, int error,
>  				unsigned int nr_bytes);
>  extern int __blk_end_request(struct request *rq, int error,
>  				unsigned int nr_bytes);
> -extern int blk_end_bidi_request(struct request *rq, int error,
> -				unsigned int nr_bytes, unsigned int bidi_bytes);
>  extern void end_request(struct request *, int);
>  extern int blk_end_request_callback(struct request *rq, int error,
>  				unsigned int nr_bytes,

Boaz

  reply	other threads:[~2008-11-30 11:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-28  5:52 [PATCH] block: integrate blk_end_bidi_request into blk_end_request FUJITA Tomonori
2008-11-30 11:10 ` Boaz Harrosh [this message]
2008-12-01  7:59   ` FUJITA Tomonori
2008-12-01  9:42     ` Boaz Harrosh
2008-12-01  9:50       ` Christoph Hellwig
2008-12-01  9:59       ` FUJITA Tomonori
2008-12-01 10:19         ` Boaz Harrosh
2008-12-01 10:26           ` FUJITA Tomonori
2008-12-01 10:42             ` Boaz Harrosh

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=493274A7.5050404@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=jens.axboe@oracle.com \
    --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.