mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson
synced 2025-08-27 15:36:48 +00:00
0bcfca5640
Rework how lib/crc/ supports arch-optimized code. First, instead of the arch-optimized CRC code being in arch/$(SRCARCH)/lib/, it will now be in lib/crc/$(SRCARCH)/. Second, the API functions (e.g. crc32c()), arch-optimized functions (e.g. crc32c_arch()), and generic functions (e.g. crc32c_base()) will now be part of a single module for each CRC type, allowing better inlining and dead code elimination. The second change is made possible by the first. As an example, consider CONFIG_CRC32=m on x86. We'll now have just crc32.ko instead of both crc32-x86.ko and crc32.ko. The two modules were already coupled together and always both got loaded together via direct symbol dependency, so the separation provided no benefit. Note: later I'd like to apply the same design to lib/crypto/ too, where often the API functions are out-of-line so this will work even better. In those cases, for each algorithm we currently have 3 modules all coupled together, e.g. libsha256.ko, libsha256-generic.ko, and sha256-x86.ko. We should have just one, inline things properly, and rely on the compiler's dead code elimination to decide the inclusion of the generic code instead of manually setting it via kconfig. Having arch-specific code outside arch/ was somewhat controversial when Zinc proposed it back in 2018. But I don't think the concerns are warranted. It's better from a technical perspective, as it enables the improvements mentioned above. This model is already successfully used in other places in the kernel such as lib/raid6/. The community of each architecture still remains free to work on the code, even if it's not in arch/. At the time there was also a desire to put the library code in the same files as the old-school crypto API, but that was a mistake; now that the library is separate, that's no longer a constraint either. Reviewed-by: "Martin K. Petersen" <martin.petersen@oracle.com> Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: "Jason A. Donenfeld" <Jason@zx2c4.com> Link: https://lore.kernel.org/r/20250607200454.73587-3-ebiggers@kernel.org Link: https://lore.kernel.org/r/20250612054514.142728-1-ebiggers@kernel.org Link: https://lore.kernel.org/r/20250621012221.4351-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
29 lines
923 B
C
29 lines
923 B
C
/* SPDX-License-Identifier: GPL-2.0 */
|
|
#ifndef _LINUX_CRC64_H
|
|
#define _LINUX_CRC64_H
|
|
|
|
#include <linux/types.h>
|
|
|
|
/**
|
|
* crc64_be - Calculate bitwise big-endian ECMA-182 CRC64
|
|
* @crc: seed value for computation. 0 or (u64)~0 for a new CRC calculation,
|
|
* or the previous crc64 value if computing incrementally.
|
|
* @p: pointer to buffer over which CRC64 is run
|
|
* @len: length of buffer @p
|
|
*/
|
|
u64 crc64_be(u64 crc, const void *p, size_t len);
|
|
|
|
/**
|
|
* crc64_nvme - Calculate CRC64-NVME
|
|
* @crc: seed value for computation. 0 for a new CRC calculation, or the
|
|
* previous crc64 value if computing incrementally.
|
|
* @p: pointer to buffer over which CRC64 is run
|
|
* @len: length of buffer @p
|
|
*
|
|
* This computes the CRC64 defined in the NVME NVM Command Set Specification,
|
|
* *including the bitwise inversion at the beginning and end*.
|
|
*/
|
|
u64 crc64_nvme(u64 crc, const void *p, size_t len);
|
|
|
|
#endif /* _LINUX_CRC64_H */
|