Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 1 Sep 2020 16:29:57 +0300
From:   Sergei Shtepa <sergei.shtepa@veeam.com>
To:     Jens Axboe <axboe@kernel.dk>
CC:     "masahiroy@kernel.org" <masahiroy@kernel.org>,
        "michal.lkml@markovi.net" <michal.lkml@markovi.net>,
        "koct9i@gmail.com" <koct9i@gmail.com>,
        "jack@suse.cz" <jack@suse.cz>,
        "damien.lemoal@wdc.com" <damien.lemoal@wdc.com>,
        "ming.lei@redhat.com" <ming.lei@redhat.com>,
        "steve@sk2.org" <steve@sk2.org>,
        "linux-kbuild@vger.kernel.org" <linux-kbuild@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [PATCH 0/1] block io layer filters api
Message-ID: <20200901132957.GA18251@veeam.com>
References: <1598555619-14792-1-git-send-email-sergei.shtepa@veeam.com>
 <7a517822-6be2-7d0d-fae3-31472c85f543@kernel.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <7a517822-6be2-7d0d-fae3-31472c85f543@kernel.dk>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

The 08/28/2020 16:54, Jens Axboe wrote:
> On 8/27/20 1:13 PM, Sergei Shtepa wrote:
> > Hello everyone! Requesting for your comments and suggestions.
> > 
> > We propose new kernel API that should be beneficial for out-of-tree
> > kernel modules of multiple backup vendors: block layer filter API.
> 
> That's just a non-starter, I'm afraid. We generally don't carry
> infrastructure in the kernel for out-of-tree modules, that includes
> even exports of existing code.
> 
> If there's a strong use case *in* the kernel, then such functionality
> could be entertained.
> 
> -- 
> Jens Axboe
>

To be honest, we've always dreamed to include our out-of-tree module into
the kernel itself - so if you're open to that, that is great news indeed!

We've spent some time before responding to estimate how long it will take
us to update the current source code to meet coding requirements.
It looks like we will need 2-4 months of development and QC, and possibly
much more to work on your feedback thereafter.
This is much work, but we are fully committed to this if you are willing
to include this module into the kernel.

However, the same time requirement also presents a big immediate problem -
as until this is done, over a hundred thousands of Linux users will not be
able to protect their servers running the impacted kernels
(our backup agent is free).
They will be forced to stop using the new version of the kernel
(or take a risk of data loss).

Given that, is there any chance that you accept the proposed patch now, to
restore the ability to protect their Linux machines - and buy us time to 
deliver the compliant module for inclusion into the kernel?

-- 
Sergei Shtepa
Veeam Software developer.