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 <colyli@xxxxxxx> >> Co-developed-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> >> Reviewed-by: Hannes Reinecke <hare@xxxxxxx> >> Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> >> Cc: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> >> Cc: Michael Lyle <mlyle@xxxxxxxx> >> Cc: Kent Overstreet <kent.overstreet@xxxxxxxxx> >> Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> >> Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx> >> Cc: Kate Stewart <kstewart@xxxxxxxxxxxxxxxxxxx> >> Cc: Eric Biggers <ebiggers3@xxxxxxxxx> >> --- >> 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 <linux/types.h> >> + >> +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
