All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bagas Sanjaya <bagasdotme@gmail.com>
To: Sergei Shtepa <sergei.shtepa@veeam.com>
Cc: axboe@kernel.dk, corbet@lwn.net, linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 01/21] documentation, blkfilter: Block Device Filtering Mechanism
Date: Sat, 10 Dec 2022 11:15:48 +0700	[thread overview]
Message-ID: <Y5QH9FdUvgZ7A8cu@debian.me> (raw)
In-Reply-To: <20221209142331.26395-2-sergei.shtepa@veeam.com>

[-- Attachment #1: Type: text/plain, Size: 5441 bytes --]

On Fri, Dec 09, 2022 at 03:23:11PM +0100, Sergei Shtepa wrote:
> The document contains:
> * Describes the purpose of the mechanism
> * A little historical background on the capabilities of handling I/O
>   units of the Linux kernel
> * Brief description of the design
> * Reference to interface description
> 

The patch subject should be "Documentation: document block device
filtering"

Also, write the patch description in imperative mood.

> diff --git a/Documentation/block/blkfilter.rst b/Documentation/block/blkfilter.rst
> new file mode 100644
> index 000000000000..3482e16c1964
> --- /dev/null
> +++ b/Documentation/block/blkfilter.rst
> @@ -0,0 +1,50 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +================================
> +Block Device Filtering Mechanism
> +================================
> +
> +The block device filtering mechanism is an API that allows to attach block
> +device filters. Block device filters allow perform additional processing
> +for I/O units.
> +
> +Introduction
> +============
> +
> +The idea of handling I/O units on block devices is not new. Back in the
> +2.6 kernel, there was an undocumented possibility of handling I/O units
> +by substituting the make_request_fn() function, which belonged to the
> +request_queue structure. But no kernel module used this feature, and it
> +was eliminated in the 5.10 kernel.
> +
> +The block device filtering mechanism returns the ability to handle I/O units.
> +It is possible to safely attach filter to a block device "on the fly" without
> +changing the structure of block devices.
> +
> +It supports attaching one filter to one block device, because there is only
> +one filter implementation in the kernel.
> +See Documentation/block/blksnap.rst.
> +
> +Design
> +======
> +
> +The block device filtering mechanism provides functions for attaching and
> +detaching the filter. The filter is a structure with a reference counter
> +and callback functions.
> +
> +The submit_bio_cb() callback function is called for each I/O unit for a block
> +device, providing I/O unit filtering. Depending on the result of filtering
> +the I/O unit, it can either be passed for subsequent processing by the block
> +layer, or skipped.
> +
> +The reference counter allows to control the filter lifetime. When the reference
> +count is reduced to zero, the release_cb() callback function is called to
> +release the filter. This allows the filter to be released when the block
> +device is disconnected.
> +
> +Interface description
> +=====================
> +.. kernel-doc:: include/linux/blkdev.h
> +	:functions: bdev_filter_operations bdev_filter bdev_filter_init bdev_filter_get bdev_filter_put
> +.. kernel-doc:: block/bdev.c
> +	:functions: bdev_filter_attach bdev_filter_detach

What about the wording below instead?

---- >8 ----
diff --git a/Documentation/block/blkfilter.rst b/Documentation/block/blkfilter.rst
index 3482e16c1964e6..fe2a4151c38fde 100644
--- a/Documentation/block/blkfilter.rst
+++ b/Documentation/block/blkfilter.rst
@@ -5,7 +5,7 @@ Block Device Filtering Mechanism
 ================================
 
 The block device filtering mechanism is an API that allows to attach block
-device filters. Block device filters allow perform additional processing
+device filters. Block device filters allow performing additional processing
 for I/O units.
 
 Introduction
@@ -14,16 +14,16 @@ Introduction
 The idea of handling I/O units on block devices is not new. Back in the
 2.6 kernel, there was an undocumented possibility of handling I/O units
 by substituting the make_request_fn() function, which belonged to the
-request_queue structure. But no kernel module used this feature, and it
-was eliminated in the 5.10 kernel.
+request_queue structure. But no kernel module used this feature, which was
+the reason why it was removed in the 5.10 kernel.
 
-The block device filtering mechanism returns the ability to handle I/O units.
-It is possible to safely attach filter to a block device "on the fly" without
+With block device filtering, the ability to handling I/O units is back. It is
+now possible to safely attaching filter to a block device "on the fly" without
 changing the structure of block devices.
 
-It supports attaching one filter to one block device, because there is only
-one filter implementation in the kernel.
-See Documentation/block/blksnap.rst.
+It supports attaching a filter to a block device, due to there is only
+one filter implementation in the kernel. See Documentation/block/blksnap.rst
+for details.
 
 Design
 ======
@@ -33,9 +33,9 @@ detaching the filter. The filter is a structure with a reference counter
 and callback functions.
 
 The submit_bio_cb() callback function is called for each I/O unit for a block
-device, providing I/O unit filtering. Depending on the result of filtering
-the I/O unit, it can either be passed for subsequent processing by the block
-layer, or skipped.
+device, providing I/O unit filtering. Depending on filtering result, it can
+either be passed for subsequent processing by the block
+layer, or be skipped.
 
 The reference counter allows to control the filter lifetime. When the reference
 count is reduced to zero, the release_cb() callback function is called to

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2022-12-10  4:16 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-09 14:23 [PATCH v2 00/21] blksnap - block devices snapshots module Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 01/21] documentation, blkfilter: Block Device Filtering Mechanism Sergei Shtepa
2022-12-10  4:15   ` Bagas Sanjaya [this message]
2022-12-09 14:23 ` [PATCH v2 02/21] block, " Sergei Shtepa
2022-12-15  9:26   ` Christoph Hellwig
2022-12-15 10:46     ` Sergei Shtepa
2022-12-16  7:04       ` Christoph Hellwig
2023-01-31 23:58   ` [dm-devel] " Mike Snitzer
2023-01-31 23:58     ` Mike Snitzer
2023-02-01 11:09     ` [dm-devel] " Fabio Fantoni
2023-02-01 11:09       ` Fabio Fantoni
2023-02-01 13:16     ` [dm-devel] " Sergei Shtepa
2023-02-01 13:16       ` Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 03/21] documentation, capability: fix Generic Block Device Capability Sergei Shtepa
2022-12-13 12:13   ` Fabio Fantoni
2022-12-30 15:35     ` Fabio Fantoni
2022-12-09 14:23 ` [PATCH v2 04/21] documentation, blksnap: Block Devices Snapshots Module Sergei Shtepa
2022-12-10  3:50   ` Bagas Sanjaya
2022-12-09 14:23 ` [PATCH v2 05/21] block, blksnap: header file of the module interface Sergei Shtepa
2022-12-09 22:13   ` kernel test robot
2022-12-09 23:14   ` kernel test robot
2022-12-09 14:23 ` [PATCH v2 06/21] block, blksnap: module management interface functions Sergei Shtepa
2022-12-15  9:28   ` Christoph Hellwig
2023-01-03 15:26   ` Pankaj Raghav
2022-12-09 14:23 ` [PATCH v2 07/21] block, blksnap: init() and exit() functions Sergei Shtepa
2022-12-15  9:30   ` Christoph Hellwig
2022-12-09 14:23 ` [PATCH v2 08/21] block, blksnap: interaction with sysfs Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 09/21] block, blksnap: attaching and detaching the filter and handling I/O units Sergei Shtepa
2022-12-15 10:01   ` Christoph Hellwig
2022-12-09 14:23 ` [PATCH v2 10/21] block, blksnap: map of change block tracking Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 11/21] block, blksnap: minimum data storage unit of the original block device Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 12/21] block, blksnap: buffer in memory for the minimum data storage unit Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 13/21] block, blksnap: functions and structures for performing block I/O operations Sergei Shtepa
2022-12-15 10:06   ` Christoph Hellwig
2022-12-09 14:23 ` [PATCH v2 14/21] block, blksnap: storage for storing difference blocks Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 15/21] block, blksnap: event queue from the difference storage Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 16/21] block, blksnap: owner of information about overwritten blocks of the original block device Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 17/21] block, blksnap: snapshot image " Sergei Shtepa
2022-12-15  9:45   ` Christoph Hellwig
2023-01-01  7:18   ` Hillf Danton
2023-01-02  9:44     ` Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 18/21] block, blksnap: snapshot Sergei Shtepa
2023-01-01 11:05   ` Hillf Danton
2023-01-02  9:58     ` Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 19/21] block, blksnap: Kconfig and Makefile Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 20/21] block, blksnap: adds a blksnap to the kernel tree Sergei Shtepa
2022-12-09 21:53   ` kernel test robot
2022-12-09 14:23 ` [PATCH v2 21/21] block, blksnap: adds a maintainer for new files Sergei Shtepa
2022-12-10  3:23 ` [PATCH v2 00/21] blksnap - block devices snapshots module Bagas Sanjaya
2022-12-10 22:57   ` Sergei Shtepa
2023-01-17 21:04 ` Mike Snitzer
2023-01-18 10:51   ` Hannes Reinecke
2023-01-24 11:34   ` Sergei Shtepa
2023-01-31 20:47     ` [dm-devel] " Mike Snitzer
2023-01-31 20:47       ` Mike Snitzer
2023-02-01  2:32       ` [dm-devel] " Mason Giles
2023-02-01  2:32         ` Mason Giles

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=Y5QH9FdUvgZ7A8cu@debian.me \
    --to=bagasdotme@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=corbet@lwn.net \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sergei.shtepa@veeam.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 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.