From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C048CC43461 for ; Wed, 16 Sep 2020 18:43:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8CA8620809 for ; Wed, 16 Sep 2020 18:43:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600281790; bh=8qlak/iJZ1weobruO4cvNi1WhYgt0OC+6iovuMs7szE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=AgfsCyH+tEthFtpRVCj10lp5u6QliN9jpRRnfD5lII9AWVWvwpLYKorA9QYxP2Wfr AAfX96StQGf2ysTo27l22cS/2ETTBqdnVCeMdj9b4eZXJ+8RgMeYSoUaWEtq2MDpxS usOYrQ8pkEwoSmX0iqn18h0UZZlx3WNH2YuRmt6E= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728192AbgIPSmf (ORCPT ); Wed, 16 Sep 2020 14:42:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:57542 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727749AbgIPS1p (ORCPT ); Wed, 16 Sep 2020 14:27:45 -0400 Received: from sol.localdomain (172-10-235-113.lightspeed.sntcca.sbcglobal.net [172.10.235.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 37BA722208; Wed, 16 Sep 2020 18:27:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600280864; bh=8qlak/iJZ1weobruO4cvNi1WhYgt0OC+6iovuMs7szE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AprUEuZQ7/3taf12uhi7pHpICffnF/MiMUikckj/6bEyw1ldvY9YVR8uPSnE2o7Ab rqf84Nw0IPvGCvX3Z9U8gIkBsFHGMF/SQYTojHEP9zH7Ewkx2/fMmeJWmLc4oPmffC zCInOFKGiYQDzrft/0Y1uKrDkkbWlaA92OD/H6Ps= Date: Wed, 16 Sep 2020 11:27:42 -0700 From: Eric Biggers To: Christoph Hellwig Cc: Chris Mason , squashfs-devel@lists.sourceforge.net, Herbert Xu , Nick Terrell , Yann Collet , Petr Malat , linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Nick Terrell , linux-crypto@vger.kernel.org, Kernel Team , Niket Agarwal , linux-btrfs@vger.kernel.org, Johannes Weiner Subject: Re: [PATCH 5/9] btrfs: zstd: Switch to the zstd-1.4.6 API Message-ID: <20200916182742.GB4373@sol.localdomain> References: <20200916034307.2092020-1-nickrterrell@gmail.com> <20200916034307.2092020-7-nickrterrell@gmail.com> <20200916084958.GC31608@infradead.org> <20200916143046.GA13543@infradead.org> <1CAB33F1-95DB-4BC5-9023-35DD2E4E0C20@fb.com> <20200916144618.GB16392@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200916144618.GB16392@infradead.org> Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org 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 Nick is interested in improving things in both places. > > Seriously, we do not care elsewhere. Why would zlib be any different? > > > There are probably 1000 constructive ways to have that conversation. Please > > choose one of those instead of being an asshole. > > I think you are the asshole here by ignoring the practices we are using > elsewhere and think your employers pet project is somehow special. It > is not, and claiming so is everything but constructive. > The userspace Zstandard library is widely used and has been heavily reviewed, tested, and fuzzed. The options are either (a) write and maintain a separate kernel implementation of Zstandard, or (b) periodically sync from upstream and make minimal, easily reviewable changes to integrate with the kernel. I don't see option (a) working for Zstandard. For short and simple code, it's the usual Linux kernel practice and it works fine. But it's far too hard to write and maintain a good implementation of Zstandard -- meaning correct, fast, fully fuzzed, and supporting all needed compression levels. Optimizing compressors and decompressors is really hard. A "naive" implementation wouldn't be too hard, but it would be slow and wouldn't support high compression ratios. Similarly, some of the crypto assembly code in the kernel is taken from the OpenSSL project, since the kernel community doesn't have the capacity to properly optimize algorithms like Poly1305 for x86, arm, arm64, mips, ... If your main concern is about the camel case function naming, that doesn't seem very important, relatively speaking. - Eric