Commit 3fdd4086 authored by Christoph Hellwig's avatar Christoph Hellwig Committed by Jens Axboe

block: improve the submit_bio and generic_make_request documentation

The current documentation is a little weird, as it doesn't clearly
explain which function to use, and also has the guts of the information
on generic_make_request, which is the internal interface for stacking
drivers.

Fix this up by properly documenting submit_bio, and only documenting
the differences and the use case for generic_make_request.
Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
Reviewed-by: default avatarKeith Busch <kbusch@kernel.org>
Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
parent e1b586f2
...@@ -992,28 +992,13 @@ generic_make_request_checks(struct bio *bio) ...@@ -992,28 +992,13 @@ generic_make_request_checks(struct bio *bio)
} }
/** /**
* generic_make_request - hand a buffer to its device driver for I/O * generic_make_request - re-submit a bio to the block device layer for I/O
* @bio: The bio describing the location in memory and on the device. * @bio: The bio describing the location in memory and on the device.
* *
* generic_make_request() is used to make I/O requests of block * This is a version of submit_bio() that shall only be used for I/O that is
* devices. It is passed a &struct bio, which describes the I/O that needs * resubmitted to lower level drivers by stacking block drivers. All file
* to be done. * systems and other upper level users of the block layer should use
* * submit_bio() instead.
* generic_make_request() does not return any status. The
* success/failure status of the request, along with notification of
* completion, is delivered asynchronously through the bio->bi_end_io
* function described (one day) else where.
*
* The caller of generic_make_request must make sure that bi_io_vec
* are set to describe the memory buffer, and that bi_dev and bi_sector are
* set to describe the device address, and the
* bi_end_io and optionally bi_private are set to describe how
* completion notification should be signaled.
*
* generic_make_request and the drivers it calls may use bi_next if this
* bio happens to be merged with someone else, and may resubmit the bio to
* a lower device by calling into generic_make_request recursively, which
* means the bio should NOT be touched after the call to ->make_request_fn.
*/ */
blk_qc_t generic_make_request(struct bio *bio) blk_qc_t generic_make_request(struct bio *bio)
{ {
...@@ -1152,10 +1137,14 @@ EXPORT_SYMBOL_GPL(direct_make_request); ...@@ -1152,10 +1137,14 @@ EXPORT_SYMBOL_GPL(direct_make_request);
* submit_bio - submit a bio to the block device layer for I/O * submit_bio - submit a bio to the block device layer for I/O
* @bio: The &struct bio which describes the I/O * @bio: The &struct bio which describes the I/O
* *
* submit_bio() is very similar in purpose to generic_make_request(), and * submit_bio() is used to submit I/O requests to block devices. It is passed a
* uses that function to do most of the work. Both are fairly rough * fully set up &struct bio that describes the I/O that needs to be done. The
* interfaces; @bio must be presetup and ready for I/O. * bio will be send to the device described by the bi_disk and bi_partno fields.
* *
* The success/failure status of the request, along with notification of
* completion, is delivered asynchronously through the ->bi_end_io() callback
* in @bio. The bio must NOT be touched by thecaller until ->bi_end_io() has
* been called.
*/ */
blk_qc_t submit_bio(struct bio *bio) blk_qc_t submit_bio(struct bio *bio)
{ {
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment