On 10 Nov 2020, at 13:39, Christoph Hellwig wrote:
On Mon, Nov 09, 2020 at 02:01:41PM -0500, Chris Mason wrote:
You do consistently ask for a shim layer, but you haven???t explained
what
we gain by diverging from the documented and tested API of the
upstream zstd
project. It???s an important
On 6 Nov 2020, at 13:38, Christoph Hellwig wrote:
You just keep resedning this crap, don't you? Haven't you been told
multiple times to provide a proper kernel API by now?
You do consistently ask for a shim layer, but you haven’t explained
what we gain by diverging from the documented and
On 2 Oct 2020, at 2:54, Christoph Hellwig wrote:
On Wed, Sep 30, 2020 at 08:05:45PM +, Nick Terrell wrote:
On Sep 29, 2020, at 11:53 PM, Christoph Hellwig
wrote:
As you keep resend this I keep retelling you that should not do it.
Please provide a proper Linux API, and switch to that.
On 17 Sep 2020, at 6:04, Christoph Hellwig wrote:
On Wed, Sep 16, 2020 at 09:35:51PM -0400, Rik van Riel wrote:
One possibility is to have a kernel wrapper on top of the zstd API
to
make it
more ergonomic. I personally don???t really see the value in it,
since
it adds
another layer of indire
On 16 Sep 2020, at 10:46, Christoph Hellwig wrote:
On Wed, Sep 16, 2020 at 10:43:04AM -0400, Chris Mason wrote:
Otherwise we just end up with drift and kernel-specific bugs that are
harder
to debug. To the extent those APIs make us contort the kernel code,
I???m
sure Nick is interested in im
On 16 Sep 2020, at 10:30, Christoph Hellwig wrote:
On Wed, Sep 16, 2020 at 10:20:52AM -0400, Chris Mason wrote:
It???s not completely clear what you???re asking for here. If the
API
matches what???s in zstd-1.4.6, that seems like a reasonable way to
label
it. That???s what the upstream is f
On 16 Sep 2020, at 4:49, Christoph Hellwig wrote:
On Tue, Sep 15, 2020 at 08:42:59PM -0700, Nick Terrell wrote:
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is functionally equivalent.
Again, please use sensible names And no one gives a fuck
