Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp564752imm; Wed, 18 Jul 2018 07:03:19 -0700 (PDT) X-Google-Smtp-Source: AAOMgpf484CHJbYV7ZLfC7plBKCnQkEIE6crSxvakSNzIOv6as3mlFRPbWj0PhGIQIu7Qp3ZRpsG X-Received: by 2002:a63:f002:: with SMTP id k2-v6mr5870462pgh.8.1531922599086; Wed, 18 Jul 2018 07:03:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531922599; cv=none; d=google.com; s=arc-20160816; b=gXbSQI52deKBcFcb9849DWMweOEfb8KF3OJFRDMcpce+Muf1r6ltNJJKsPfydDhpdt N9ldnpct50epADx9cWEorgM44povhMY3LJjg5LnC9AkDL+/u1wOfUO0GPHg0Cqc6pBRz dm8+wuPEwRnc0KDF527ETNATcqsk3B0AdGg88Vz+vFZzeCGVgSDLaCAp3Au9Y3jADYr/ hOUzqL8Q/Sw/HOljgOa1dgR+U5q6IwxUizxLrFZ95F9WI1vOvEVEIq6xBaUykCjEPFa5 ivi+zixl0DNsNfqXF+cMSyPPgBKUndi+0b784mwqTYOjCIvLVm6Sfhk13ce1Q1tquPqb hHrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:autocrypt:openpgp:from:references:cc:to:subject :arc-authentication-results; bh=PEj9MEDI6YsCaG8JbPYZtRZnVo0a0dJkF9sXCBz3plQ=; b=t197ln8bVAUu/vVH+HWy4UlUjXgXVOmvYPI888AbYu8QWal9/Ecxt9J0q9T+nTslta s77oajGzFkvnPdLXRzIeM7mGI8PC5/ktSlADFD4ZvzSjDfdG4OrsYpkEhn3XoACNXiOX yctahAjJQrrb/LmLU7T4iGbtXztPiYMZRhmro0f4M9vQtSEeqh8XzHpmYbRYTVdvpzpo jLqcAk9Eg1Dy2fjKUdZo+KM73ugkEznuwrpBWO9r50ve4arjezoOYqvOrbuvXHiDtqwQ gDkyvf32FKjiiY7IarFYtMVyc/7eF5wJX6tXVOup/eb+mh+2BZpMP9M5t27DC/ZqNLxP CRzQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i2-v6si3253852pgh.565.2018.07.18.07.03.02; Wed, 18 Jul 2018 07:03:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730302AbeGROka (ORCPT + 99 others); Wed, 18 Jul 2018 10:40:30 -0400 Received: from mx2.suse.de ([195.135.220.15]:42916 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728311AbeGROk3 (ORCPT ); Wed, 18 Jul 2018 10:40:29 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 68E74AE9A; Wed, 18 Jul 2018 14:02:19 +0000 (UTC) Subject: Re: [PATCH v3 1/3] lib: add crc64 calculation routines To: Eric Biggers Cc: linux-kernel@vger.kernel.org, linux-bcache@vger.kernel.org, linux-block@vger.kernel.org, Greg Kroah-Hartman , Andy Shevchenko , Michael Lyle , Kent Overstreet , Linus Torvalds , Thomas Gleixner , Kate Stewart , Andrew Morton References: <20180717145525.50852-1-colyli@suse.de> <20180717145525.50852-2-colyli@suse.de> <20180717163116.GA75957@gmail.com> From: Coly Li Openpgp: preference=signencrypt Autocrypt: addr=colyli@suse.de; prefer-encrypt=mutual; keydata= xsFNBFYX6S8BEAC9VSamb2aiMTQREFXK4K/W7nGnAinca7MRuFUD4JqWMJ9FakNRd/E0v30F qvZ2YWpidPjaIxHwu3u9tmLKqS+2vnP0k7PRHXBYbtZEMpy3kCzseNfdrNqwJ54A430BHf2S GMVRVENiScsnh4SnaYjFVvB8SrlhTsgVEXEBBma5Ktgq9YSoy5miatWmZvHLFTQgFMabCz/P j5/xzykrF6yHo0rHZtwzQzF8rriOplAFCECp/t05+OeHHxjSqSI0P/G79Ll+AJYLRRm9til/ K6yz/1hX5xMToIkYrshDJDrUc8DjEpISQQPhG19PzaUf3vFpmnSVYprcWfJWsa2wZyyjRFkf J51S82WfclafNC6N7eRXedpRpG6udUAYOA1YdtlyQRZa84EJvMzW96iSL1Gf+ZGtRuM3k49H 1wiWOjlANiJYSIWyzJjxAd/7Xtiy/s3PRKL9u9y25ftMLFa1IljiDG+mdY7LyAGfvdtIkanr iBpX4gWXd7lNQFLDJMfShfu+CTMCdRzCAQ9hIHPmBeZDJxKq721CyBiGAhRxDN+TYiaG/UWT 7IB7LL4zJrIe/xQ8HhRO+2NvT89o0LxEFKBGg39yjTMIrjbl2ZxY488+56UV4FclubrG+t16 r2KrandM7P5RjR+cuHhkKseim50Qsw0B+Eu33Hjry7YCihmGswARAQABzRhDb2x5IExpIDxj b2x5bGlAc3VzZS5kZT7CwX8EEwEIACkFAlYX6ZACGyMFCQlmAYAHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDHOQeTa334/CncD/9B97EIjcDOm0TS164bpMlsbZWEm8GQnV6nVzm8 QsywPRM8S8nqkqX1atTYl/fTdJsasH8mgryUqL0eHBPs5RmJhDk3YgYsTrzbOjMdsdRwv24W J5RXdulRag2XDPIhSP7rWsOSh66gljdAp8XQQZD0zFXi4IytoAuLtx8RMjzzKk1iP6uz8MIv em7iFu6NYcHd3cmvSPo7CnBVaG0dZ6P2p2gS7ydSWOGsWkNh/XM4ojJaX1ZdCeFR0XLS76Gi 6e01DoN2UsqZE/TQu1czYMMA1uM/Es6ZTYgobTrrnNB79ctqgtbBrjME5sOHLX40ccbBI3QB Ta4opSp8VqUMXw/yd5ckLPocnkJBTVxuaOfRhpxr6gWeudrkMetMj+39yeklskP7up0JvAUG 7/HjjqwWR7xAaZHmZORYsIxJ9ploBb8eSqHHx+7489ZDNLP+WCsAonpKTdJNAzGJClnLFxKS DY4cOPs7o4IFBk6dVXJWMqyLGwmMQ51Pq6BID4epaAuuBAL6x7n7NrFPuS68Fn/VaxqMEld9 L2eCi4cv++1AJyMF3iQKT56I8BjHEuf0wo1tmZ3BgBT19xRsEl7YItixxtYQm66Pb4lSQQmE Ep+uQNwaqPpeAU+vkDg/0Q+dhPTsvwx0OAI30HwhuzNA8OIfHBx7dJNm0b0fg5x0pg3LDM7B TQRWF+kvARAA2T/tnJeA0RWkmgZrNPFvP7JnOU9gjmIQKMoGZ+9awew45pdmXb6y0Y0fEG59 EP9i9oBlFXOt6SZ2645V0sdi3wBRNEpX2CCddWhXRfcO0b6lgckIwyaK92dH1rzxMaZTYDL8 aQ9FNEK1U+XSBk8fYWnXowpf7oNPS6+jD0J/muPqrGkVsIAkh2iLg5B98yNTCV4ql1xSlMyf xcseke9q6ojDxx9p38JjLusDlwF2+/rF42c+T6PRiYNjnBHPq6VLSlCRsnkLJwg8VHKiV2Qw Yvxp4TwnK2kLqokOxBlriX45Odb2iP61uG2ZAPchDwfawWJ4G8+3EMplLH8bk0/DkpYcYz95 eGSGRSiIQ2kHmTI/KbpgXxFVMoheilUn4HzUP+T6TEeP6Zhm0aqwABJYa0T2ykJwpBlg6/Mx vgIzdSheqx2hYACDu07WfhdvI6uK3i5Lq9DebUBcMMBcMc0TnXix7mYy+3hLXJzZ80pFx3My 5FeJEN/r6/+xpuuZkH51aYOiacKVa2w2EHjhZcWfPhhEWOQ2oOCoCmv+HEmV9sf+fipEMfcB 8GnJMOYAwrwHWfkPNZ5urUcRGAQYlQ0GWKju97LYE2cq5McpFG0CMvDyPoO1zAwjJz4g53EK oH/eikd3L8OMDfEK4AOsUaPMTnNgt1+40zEFMrQs/dDMldUAEQEAAcLBZQQYAQgADwUCVhfp LwIbDAUJCWYBgAAKCRDHOQeTa334/PtREACDN8W/pHeHyPW/mTt6MEe/GICG5YdlBW5ft7HY Cf6rTz+uLZolGc5SYKuJJ0JC/L2Ifh3BWmwLIOxV868KB3oEfmGszBY+4n/icLyIEAkkthBb 2V5sP5KgB3bOg7mSFBxfHi2pyO9K9d+Lr+UkORjCGyV33QFrcN+OQdPDactontnQglB7xm2K phGWqxoqepHCqFIulZ3yKGhQhmdpyz0J19Ry6GkxPE85MG/NC98D5+4Yn/V3G+yZpbGsuFhE CP26JvdXh1jNCUdU46pEjZwu0GXBIo6r1cb1v+swfYB86NeFUHWtvxamh8i6RBl1FLDhN6xb r9f7M++xoADyzPQYQPQUxWK+iG6lz3qVVq5312z/is3fcdyESPNs09DMT43xCCBr9UOMq6dZ IC9EsSeMYv4librfuSRqH4R0MuVbVWLJFg/Q7s+nbPb2YjhqIYr51hBDyXpzUDoIz43maIPk UmCNKa43mNFktMrwU21J5lVXEwBuTY6JlHOAl0Fgo28X+eTa8fx2Uiz9OVgWe03ebJGIGowe XTgqVWJMsKM1tmW+QFmgtczDGRYCZ6OQYpqt0SoTg1yx5MN4RzUtlLka2qLfPiOGUUN3qNJ5 nP+spvF+s+dHtLjjhy7AL86N01a6S0rwaClVVv0XTucvIntwccIx0CZfUKlfn5BWnB64Ig== Message-ID: Date: Wed, 18 Jul 2018 22:02:09 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180717163116.GA75957@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018/7/18 12:31 AM, Eric Biggers wrote: > Hi Coly, > > On Tue, Jul 17, 2018 at 10:55:23PM +0800, Coly Li wrote: >> This patch adds the re-write crc64 calculation routines for Linux kernel. >> The CRC64 polynomical arithmetic follows ECMA-182 specification, inspired >> by CRC paper of Dr. Ross N. Williams >> (see http://www.ross.net/crc/download/crc_v3.txt) and other public domain >> implementations. > > Please also mention who is planned to use this CRC-64 code. Again, if it's just > one user then there's no need for this patchset yet. If bcachefs is planned to > be another user (separate from bcache) then you need to say so. > >> >> All the changes work in this way, >> - When Linux kernel is built, host program lib/gen_crc64table.c will be >> compiled to lib/gen_crc64table and executed. >> - The output of gen_crc64table execution is an array called as lookup >> table (a.k.a POLY 0x42f0e1eba9ea369) which contain 256 64bits-long >> numbers, this talbe is dumped into header file lib/crc64table.h. >> - Then the header file is included by lib/crc64.c for normal 64bit crc >> calculation. >> - Function declaration of the crc64 calculation routines is placed in >> include/linux/crc64.h >> >> Changelog: >> v3: More fixes for review comments of v2 >> By review comments from Eric Biggers, current functions naming with >> 'le' is misleading. Remove 'le' from the crc function names, and use >> u64 to replace __le64 in parameters and return values. >> v2: Fix reivew comments of v1 >> v1: Initial version. >> >> Signed-off-by: Coly Li >> Co-developed-by: Andy Shevchenko >> Reviewed-by: Hannes Reinecke >> Cc: Greg Kroah-Hartman >> Cc: Andy Shevchenko >> Cc: Michael Lyle >> Cc: Kent Overstreet >> Cc: Linus Torvalds >> Cc: Thomas Gleixner >> Cc: Kate Stewart >> Cc: Eric Biggers >> --- >> include/linux/crc64.h | 13 ++++++++ >> lib/.gitignore | 2 ++ >> lib/Kconfig | 8 +++++ >> lib/Makefile | 11 +++++++ >> lib/crc64.c | 71 +++++++++++++++++++++++++++++++++++++++++++ >> lib/gen_crc64table.c | 69 +++++++++++++++++++++++++++++++++++++++++ >> 6 files changed, 174 insertions(+) >> create mode 100644 include/linux/crc64.h >> create mode 100644 lib/crc64.c >> create mode 100644 lib/gen_crc64table.c >> >> diff --git a/include/linux/crc64.h b/include/linux/crc64.h >> new file mode 100644 >> index 000000000000..3e87b61cd54f >> --- /dev/null >> +++ b/include/linux/crc64.h >> @@ -0,0 +1,13 @@ >> +/* SPDX-License-Identifier: GPL-2.0 */ >> +/* >> + * See lib/crc64.c for the related specification and polynomical arithmetic. >> + */ >> +#ifndef _LINUX_CRC64_H >> +#define _LINUX_CRC64_H >> + >> +#include >> + >> +u64 __pure crc64_update(u64 crc, const void *_p, size_t len); >> +u64 __pure crc64(const void *p, size_t len); >> +u64 __pure crc64_bch(const void *p, size_t len); >> +#endif /* _LINUX_CRC64_H */ > > I still think you should make the API consistent with lib/crc32.c by replacing > the three functions with just: > > u64 __pure crc64_be(u64 crc, const void *p, size_t len); > > Your API maps to it as follows: > > crc64_update(crc, p, len) == crc64_be(crc, p, len) > crc64(p, len) == crc64_be(0, p, len) > crc64_bch(p, len) == ~crc64_be(~0, p, len) > > The "_be" suffix clarifies that it's not using the bit-reversed convention. We > don't want to have to rename everything when someone needs to do CRC-64 using > the other convention. The CRC-64 in the .xz file format, for example, uses the > bit-reversed convention. > > The other problem with your API (besides it being inconsistent with lib/crc32.c) > is that as soon as the caller needs to do something nontrivial, like passing the > data in multiple chunks or using different conventions for the initial and final > values, then they actually have to use only "crc64_update()" anyway, which is > confusing as it makes it sound like there should be a "crc64_init()" and > "crc64_final()" to go along with "crc64_update()". > > Also, naming CRC conventions after a specific user ("bch") isn't appropriate. Agree. I will only keep crc64_be() in lib/crc64.c, and move the rested back to bcache code with proper names. The change will be in v4 series. Thanks. Coly Li