[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7bd31238-0c7c-ed6f-d0b9-680fcaa54513@infradead.org>
Date: Wed, 21 Oct 2020 08:09:18 -0700
From: Randy Dunlap <rdunlap@...radead.org>
To: Sergei Shtepa <sergei.shtepa@...am.com>, axboe@...nel.dk,
viro@...iv.linux.org.uk, hch@...radead.org,
darrick.wong@...cle.com, linux-xfs@...r.kernel.org,
linux-fsdevel@...r.kernel.org, rjw@...ysocki.net,
len.brown@...el.com, pavel@....cz, akpm@...ux-foundation.org,
johannes.thumshirn@....com, ming.lei@...hat.com, jack@...e.cz,
tj@...nel.org, gustavo@...eddedor.com, bvanassche@....org,
osandov@...com, koct9i@...il.com, damien.lemoal@....com,
steve@....org, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [PATCH 1/2] Block layer filter - second version
On 10/21/20 2:04 AM, Sergei Shtepa wrote:
> diff --git a/block/Kconfig b/block/Kconfig
> index bbad5e8bbffe..a308801b4376 100644
> --- a/block/Kconfig
> +++ b/block/Kconfig
> @@ -204,6 +204,17 @@ config BLK_INLINE_ENCRYPTION_FALLBACK
> by falling back to the kernel crypto API when inline
> encryption hardware is not present.
>
> +config BLK_FILTER
> + bool "Enable support for block layer filters"
> + default y
Drop the default y. We don't add modules to a default build without
some tough justification.
> + depends on MODULES
> + help
> + Enabling this lets third-party kernel modules intercept
lets loadable kernel modules intercept
> + bio requests for any block device. This allows them to implement
> + changed block tracking and snapshots without any reconfiguration of
> + the existing setup. For example, this option allows snapshotting of
> + a block device without adding it to LVM.
--
~Randy
Powered by blists - more mailing lists