linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org
Subject: [PATCH 01/11] block: improve the kerneldoc comments for submit_bio and generic_make_request
Date: Sat, 25 Apr 2020 19:09:34 +0200	[thread overview]
Message-ID: <20200425170944.968861-2-hch@lst.de> (raw)
In-Reply-To: <20200425170944.968861-1-hch@lst.de>

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: Christoph Hellwig <hch@lst.de>
---
 block/blk-core.c | 35 ++++++++++++-----------------------
 1 file changed, 12 insertions(+), 23 deletions(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index dffff21008886..68351ee94ad2e 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -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.
  *
- * generic_make_request() is used to make I/O requests of block
- * devices. It is passed a &struct bio, which describes the I/O that needs
- * to be done.
- *
- * 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.
+ * This is a version of submit_bio() that shall only be used for I/O that is
+ * resubmitted to lower level drivers by stacking block drivers.  All file
+ * systems and other upper level users of the block layer should use
+ * submit_bio() instead.
  */
 blk_qc_t generic_make_request(struct bio *bio)
 {
@@ -1152,10 +1137,14 @@ EXPORT_SYMBOL_GPL(direct_make_request);
  * submit_bio - submit a bio to the block device layer for I/O
  * @bio: The &struct bio which describes the I/O
  *
- * submit_bio() is very similar in purpose to generic_make_request(), and
- * uses that function to do most of the work. Both are fairly rough
- * interfaces; @bio must be presetup and ready for I/O.
+ * submit_bio() is used to submit I/O requests to block devices.  It is passed a
+ * fully set up &struct bio that describes the I/O that needs to be done.  The
+ * 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)
 {
-- 
2.26.1


  reply	other threads:[~2020-04-25 17:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-25 17:09 [RFC] more make_request optimizations Christoph Hellwig
2020-04-25 17:09 ` Christoph Hellwig [this message]
2020-04-26  2:59   ` [PATCH 01/11] block: improve the kerneldoc comments for submit_bio and generic_make_request Ming Lei
2020-04-25 17:09 ` [PATCH 02/11] block: cleanup the memory stall accounting in submit_bio Christoph Hellwig
2020-04-25 17:09 ` [PATCH 03/11] block: replace BIO_QUEUE_ENTERED with BIO_CGROUP_ACCT Christoph Hellwig
2020-04-25 17:09 ` [PATCH 04/11] block: add a bio_queue_enter helper Christoph Hellwig
2020-04-25 17:09 ` [PATCH 05/11] block: refactor generic_make_request Christoph Hellwig
2020-04-25 17:09 ` [PATCH 06/11] block: optimize generic_make_request for direct to blk-mq issue Christoph Hellwig
2020-04-26  2:53   ` Ming Lei
2020-04-27 15:10     ` Christoph Hellwig
2020-04-25 17:09 ` [PATCH 07/11] block: optimize do_make_request " Christoph Hellwig
2020-04-25 17:09 ` [PATCH 08/11] block: move the call to blk_queue_enter_live out of blk_mq_get_request Christoph Hellwig
2020-04-25 17:09 ` [PATCH 09/11] block: remove a pointless queue enter pair in blk_mq_alloc_request Christoph Hellwig
2020-04-25 17:09 ` [PATCH 10/11] block: remove a pointless queue enter pair in blk_mq_alloc_request_hctx Christoph Hellwig
2020-04-25 17:09 ` [PATCH 11/11] block: allow blk_mq_make_request to consume the q_usage_counter reference Christoph Hellwig

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=20200425170944.968861-2-hch@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=linux-block@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;
as well as URLs for NNTP newsgroup(s).