> On Sep 17, 2020, at 7:28 AM, Chris Mason wrote:
>
> 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 d
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 Sep 16, 2020, at 7:46 AM, 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
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 indirection between zstd and the caller, bu
On Wed, 2020-09-16 at 15:18 -0400, Nick Terrell wrote:
> The zstd version in the kernel works fine. But, you can see that the
> version
> that got imported stagnated where upstream had 14 released versions.
> I
> don't think it makes sense to have kernel developers maintain their
> own copy
> of z
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
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 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 improving things in both places.
Seriously, we do no
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 for this code.
>
> I???m also not sure why we???re
On Wed, Sep 16, 2020 at 03:46:18PM +0100, 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
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 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 if this bad
API is "zstd-1.4.6" as the Linux ke
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is functionally equivalent.
Signed-off-by: Nick Terrell
---
fs/btrfs/zstd.c | 48
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/fs/btr
13 matches
Mail list logo
