From: Mike Christie <michaelc@cs.wisc.edu>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH 1/2] block: Modify blk_rq_map_user to support large requests
Date: Wed, 13 Sep 2006 14:38:08 -0500 [thread overview]
Message-ID: <45085E20.7070003@cs.wisc.edu> (raw)
In-Reply-To: <20060913093009.GF23515@kernel.dk>
Jens Axboe wrote:
> On Sat, Sep 09 2006, Mike Christie wrote:
>> Currently, there is some duplication between bsg, scsi_ioctl.c
>> and scsi_lib.c/sg/st in its mapping code. This patch modifies
>> the block layer blk_rq_map_user code to support large requests so
>> that the scsi and block drivers can use this common code. The
>> changes also make it so the callers do not have to account for
>> the bio to be unmapped and bounce buffers.
>>
>> The next patch then coverts bsg.c, scsi_ioctl.c and cdrom.c
>> to use the updated functions. For scsi_ioctl.c and cdrom.c
>> the only thing that changes is that they no longer have
>> to do the bounce buffer management and pass in the len for
>> the unmapping. The bsg change is a little larger since that
>> code was duplicating a lot of code that is now common
>> in the block layer. The bsg conversions als should fix
>> a memory leak caused when unmapping a hdr with iovec_count=0.
>>
>> Patch was made over Jens's block tree and the bsg branch
>
> Generally it looks good - two comments:
>
> - I see some advantages to having biohead_orig to avoid keeping track of
> it and passing it around, but there's also good reasons for _not_
> adding more stuff to struct request. Any particular reason you chose
> to do that?
I think I originally made a mistake with the bounce buffers and thinking
that others may do the same I felt that hiding a lot of the magic that
is going on in blk_rq_map_user was nice. By adding the field to the
request, the caller would only have to map the data and then unmap the
request. Since not even a handful of drivers would ever use the api, I
agree that adding the field for this limited use could be overkill.
>
> - blk_get_bounced_bio() looks redundant. BIO_BOUNCED should only be set
> on a bounced bio, and ->bi_private should always hold that bounced
> bio.
>
Ok, I will remove that.
prev parent reply other threads:[~2006-09-13 19:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-09 20:53 [PATCH 1/2] block: Modify blk_rq_map_user to support large requests Mike Christie
2006-09-13 9:30 ` Jens Axboe
2006-09-13 19:38 ` Mike Christie [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=45085E20.7070003@cs.wisc.edu \
--to=michaelc@cs.wisc.edu \
--cc=axboe@kernel.dk \
--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.