[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <D9338FE4-1518-4C7B-8C23-DBDC542DAC35@fb.com>
Date: Mon, 09 Nov 2020 14:01:41 -0500
From: "Chris Mason" <clm@...com>
To: Christoph Hellwig <hch@...radead.org>
CC: Nick Terrell <nickrterrell@...il.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
<linux-crypto@...r.kernel.org>, <linux-btrfs@...r.kernel.org>,
<squashfs-devel@...ts.sourceforge.net>,
<linux-f2fs-devel@...ts.sourceforge.net>,
<linux-kernel@...r.kernel.org>, Kernel Team <Kernel-team@...com>,
Nick Terrell <terrelln@...com>, Petr Malat <oss@...at.biz>,
Johannes Weiner <jweiner@...com>,
Niket Agarwal <niketa@...com>, Yann Collet <cyan@...com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v5 1/9] lib: zstd: Add zstd compatibility wrapper
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 tested API of the
upstream zstd project. It’s an important discussion given that we
hope to regularly update the kernel side as they make improvements in
zstd.
The only benefit described so far seems to be camelcase related, but if
there are problems in the API beyond that, I haven’t seen you describe
them. I don’t think the camelcase alone justifies the added costs of
the shim.
-chris
Powered by blists - more mailing lists