56e0790c7f
Depending on supported extensions on specific RISC-V cores, optimized str* functions might make sense. This adds basic infrastructure to allow patching the function calls via alternatives later on. The Linux kernel provides standard implementations for string functions but when architectures want to extend them, they need to provide their own. The added generic string functions are done in assembler (taken from disassembling the main-kernel functions for now) to allow us to control the used registers and extend them with optimized variants. This doesn't override the compiler's use of builtin replacements. So still first of all the compiler will select if a builtin will be better suitable i.e. for known strings. For all regular cases we will want to later select possible optimized variants and in the worst case fall back to the generic implemention added with this change. Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Heiko Stuebner <heiko.stuebner@vrull.eu> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230113212301.3534711-2-heiko@sntech.de Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
21 lines
432 B
C
21 lines
432 B
C
// SPDX-License-Identifier: GPL-2.0-only
|
|
/*
|
|
* Copyright (C) 2017 Zihao Yu
|
|
*/
|
|
|
|
#include <linux/export.h>
|
|
#include <linux/uaccess.h>
|
|
|
|
/*
|
|
* Assembly functions that may be used (directly or indirectly) by modules
|
|
*/
|
|
EXPORT_SYMBOL(memset);
|
|
EXPORT_SYMBOL(memcpy);
|
|
EXPORT_SYMBOL(memmove);
|
|
EXPORT_SYMBOL(strcmp);
|
|
EXPORT_SYMBOL(strlen);
|
|
EXPORT_SYMBOL(strncmp);
|
|
EXPORT_SYMBOL(__memset);
|
|
EXPORT_SYMBOL(__memcpy);
|
|
EXPORT_SYMBOL(__memmove);
|