| Message ID | 20211206124715.4101571-1-mark.rutland@arm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | linkage: better symbol aliasing | expand |
On Mon, 6 Dec 2021 at 13:47, Mark Rutland <mark.rutland@arm.com> wrote: > > This series aims to make symbol aliasing simpler and more consistent. > The basic idea is to replace SYM_FUNC_START_ALIAS(alias) and > SYM_FUNC_END_ALIAS(alias) with a new SYM_FUNC_ALIAS(alias, name), so > that e.g. > > SYM_FUNC_START(func) > SYM_FUNC_START_ALIAS(alias1) > SYM_FUNC_START_ALIAS(alias2) > ... asm insns ... > SYM_FUNC_END(func) > SYM_FUNC_END_ALIAS(alias1) > SYM_FUNC_END_ALIAS(alias2) > EXPORT_SYMBOL(alias1) > EXPORT_SYMBOL(alias2) > > ... can become: > > SYM_FUNC_START(name) > ... asm insns ... > SYM_FUNC_END(name) > > SYM_FUNC_ALIAS(alias1, func) > EXPORT_SYMBOL(alias1) > > SYM_FUNC_ALIAS(alias2, func) > EXPORT_SYMBOL(alias2) > > This avoids repetition and hopefully make it easier to ensure > consistency (e.g. so each function has a single canonical name and > associated metadata). > > I'm sending this as an RFC since I want to check: > > a) People are happy with the idea in principle. > > b) People are happy with the implementation within <linux/linkage.h>. > > ... and I haven't yet converted the headers under tools/, which is > largely a copy+paste job. > > I've build+boot tested arm64 and x86 defconfig without issues, and I've > pushed the series to my `linkage/alias-rework` branch on git.kernel.org, > atop v5.16-rc3: > > git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git linkage/alias-rework > https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=linkage/alias-rework > > Thanks, > Mark. > > Mark Rutland (6): > linkage: add SYM_{ENTRY,START,END}_AT() > linkage: add SYM_FUNC_{LOCAL_,}ALIAS() > arm64: remove __dma_*_area() aliases > arm64: clean up symbol aliasing > x86: clean up symbol aliasing > linkage: remove START/END ALIAS macros > I never understood why we had these start/end markers in the first place for alias definitions, so good riddance. Acked-by: Ard Biesheuvel <ardb@kernel.org> > Documentation/asm-annotations.rst | 11 ++-- > arch/arm64/include/asm/linkage.h | 24 --------- > arch/arm64/kvm/hyp/nvhe/cache.S | 5 +- > arch/arm64/lib/clear_page.S | 5 +- > arch/arm64/lib/copy_page.S | 5 +- > arch/arm64/lib/memchr.S | 5 +- > arch/arm64/lib/memcmp.S | 6 +-- > arch/arm64/lib/memcpy.S | 21 ++++---- > arch/arm64/lib/memset.S | 12 +++-- > arch/arm64/lib/strchr.S | 6 ++- > arch/arm64/lib/strcmp.S | 6 +-- > arch/arm64/lib/strlen.S | 6 +-- > arch/arm64/lib/strncmp.S | 8 +-- > arch/arm64/lib/strnlen.S | 6 ++- > arch/arm64/lib/strrchr.S | 5 +- > arch/arm64/mm/cache.S | 59 +++++++++----------- > arch/x86/boot/compressed/head_32.S | 3 +- > arch/x86/boot/compressed/head_64.S | 3 +- > arch/x86/lib/memcpy_64.S | 10 ++-- > arch/x86/lib/memmove_64.S | 4 +- > arch/x86/lib/memset_64.S | 6 +-- > include/linux/linkage.h | 86 ++++++++++++++++++------------ > 22 files changed, 146 insertions(+), 156 deletions(-) > > -- > 2.30.2 >
On Mon, Dec 06, 2021 at 03:06:44PM +0100, Ard Biesheuvel wrote: > I never understood why we had these start/end markers in the first > place for alias definitions, so good riddance. > Acked-by: Ard Biesheuvel <ardb@kernel.org> What Ard said: Acked-by: Mark Brown <broonie@kernel.org>
On Mon, Dec 06, 2021 at 12:47:09PM +0000, Mark Rutland wrote: > This avoids repetition and hopefully make it easier to ensure > consistency (e.g. so each function has a single canonical name and > associated metadata). > > I'm sending this as an RFC since I want to check: > > a) People are happy with the idea in principle. > > b) People are happy with the implementation within <linux/linkage.h>. > > ... and I haven't yet converted the headers under tools/, which is > largely a copy+paste job. Looks like a definite improvement to me. The only suggestion I'd have would be to fix a minor naming inconsistency: change "SYM_FUNC_LOCAL_ALIAS" to "SYM_FUNC_ALIAS_LOCAL" to match the other "<noun>_<verb>" macros.
On Mon, Dec 06, 2021 at 09:23:04PM -0800, Josh Poimboeuf wrote: > On Mon, Dec 06, 2021 at 12:47:09PM +0000, Mark Rutland wrote: > > This avoids repetition and hopefully make it easier to ensure > > consistency (e.g. so each function has a single canonical name and > > associated metadata). > > > > I'm sending this as an RFC since I want to check: > > > > a) People are happy with the idea in principle. > > > > b) People are happy with the implementation within <linux/linkage.h>. > > > > ... and I haven't yet converted the headers under tools/, which is > > largely a copy+paste job. > > Looks like a definite improvement to me. > > The only suggestion I'd have would be to fix a minor naming > inconsistency: change "SYM_FUNC_LOCAL_ALIAS" to "SYM_FUNC_ALIAS_LOCAL" > to match the other "<noun>_<verb>" macros. Sure; I was following the example set by `SYM_FUNC_START_LOCAL_ALIAS`, but I agree that placing LOCAL on the end looks more consistent overall once that's removed. For V2 I'll make that `SYM_FUNC_ALIAS_LOCAL`. Thanks, Mark.
On Mon, Dec 06, 2021 at 12:47:09PM +0000, Mark Rutland wrote: > This series aims to make symbol aliasing simpler and more consistent. > The basic idea is to replace SYM_FUNC_START_ALIAS(alias) and > SYM_FUNC_END_ALIAS(alias) with a new SYM_FUNC_ALIAS(alias, name), so > that e.g. > > SYM_FUNC_START(func) > SYM_FUNC_START_ALIAS(alias1) > SYM_FUNC_START_ALIAS(alias2) > ... asm insns ... > SYM_FUNC_END(func) > SYM_FUNC_END_ALIAS(alias1) > SYM_FUNC_END_ALIAS(alias2) > EXPORT_SYMBOL(alias1) > EXPORT_SYMBOL(alias2) > > ... can become: > > SYM_FUNC_START(name) > ... asm insns ... > SYM_FUNC_END(name) > > SYM_FUNC_ALIAS(alias1, func) > EXPORT_SYMBOL(alias1) > > SYM_FUNC_ALIAS(alias2, func) > EXPORT_SYMBOL(alias2) > > This avoids repetition and hopefully make it easier to ensure > consistency (e.g. so each function has a single canonical name and > associated metadata). > > I'm sending this as an RFC since I want to check: > > a) People are happy with the idea in principle. > > b) People are happy with the implementation within <linux/linkage.h>. > > ... and I haven't yet converted the headers under tools/, which is > largely a copy+paste job. I'm happy with the approach and acked the arm64 patches for the record. Not sure how/when this series will get into mainline.
On Fri, Dec 10, 2021 at 03:04:45PM +0000, Catalin Marinas wrote: > On Mon, Dec 06, 2021 at 12:47:09PM +0000, Mark Rutland wrote: > > This series aims to make symbol aliasing simpler and more consistent. > > The basic idea is to replace SYM_FUNC_START_ALIAS(alias) and > > SYM_FUNC_END_ALIAS(alias) with a new SYM_FUNC_ALIAS(alias, name), so > > that e.g. > > > > SYM_FUNC_START(func) > > SYM_FUNC_START_ALIAS(alias1) > > SYM_FUNC_START_ALIAS(alias2) > > ... asm insns ... > > SYM_FUNC_END(func) > > SYM_FUNC_END_ALIAS(alias1) > > SYM_FUNC_END_ALIAS(alias2) > > EXPORT_SYMBOL(alias1) > > EXPORT_SYMBOL(alias2) > > > > ... can become: > > > > SYM_FUNC_START(name) > > ... asm insns ... > > SYM_FUNC_END(name) > > > > SYM_FUNC_ALIAS(alias1, func) > > EXPORT_SYMBOL(alias1) > > > > SYM_FUNC_ALIAS(alias2, func) > > EXPORT_SYMBOL(alias2) > > > > This avoids repetition and hopefully make it easier to ensure > > consistency (e.g. so each function has a single canonical name and > > associated metadata). > > > > I'm sending this as an RFC since I want to check: > > > > a) People are happy with the idea in principle. > > > > b) People are happy with the implementation within <linux/linkage.h>. > > > > ... and I haven't yet converted the headers under tools/, which is > > largely a copy+paste job. > > I'm happy with the approach and acked the arm64 patches for the record. > Not sure how/when this series will get into mainline. Thanks! As to "when", I think I'm going to rework the series atop v5.17-rc1, so for now would you be happy to pick patch 3 ("arm64: remove __dma_*_area() aliases"): https://lore.kernel.org/linux-arm-kernel/20211206124715.4101571-4-mark.rutland@arm.com/ ... into the arm64 tree? That'a a pure cleanup with no dependency on the rest of the series. For the rest of the series I still need to to the mechanical work for tools/, there's a token-pasting issue on 32-bit arm, and I'd like to give this a long soak in -next, so earlier in the next window seems like a better bet. As for "how", I assume the core linkage bits will go via the tip tree, so I think it'd make sense for the (remaining) arch bits to go that way too. Thanks, Mark.
On Mon, 6 Dec 2021 12:47:09 +0000, Mark Rutland wrote: > This series aims to make symbol aliasing simpler and more consistent. > The basic idea is to replace SYM_FUNC_START_ALIAS(alias) and > SYM_FUNC_END_ALIAS(alias) with a new SYM_FUNC_ALIAS(alias, name), so > that e.g. > > SYM_FUNC_START(func) > SYM_FUNC_START_ALIAS(alias1) > SYM_FUNC_START_ALIAS(alias2) > ... asm insns ... > SYM_FUNC_END(func) > SYM_FUNC_END_ALIAS(alias1) > SYM_FUNC_END_ALIAS(alias2) > EXPORT_SYMBOL(alias1) > EXPORT_SYMBOL(alias2) > > [...] Applied to arm64 (for-next/misc), thanks! [3/6] arm64: remove __dma_*_area() aliases https://git.kernel.org/arm64/c/c2c529b27ceb
This series aims to make symbol aliasing simpler and more consistent. The basic idea is to replace SYM_FUNC_START_ALIAS(alias) and SYM_FUNC_END_ALIAS(alias) with a new SYM_FUNC_ALIAS(alias, name), so that e.g. SYM_FUNC_START(func) SYM_FUNC_START_ALIAS(alias1) SYM_FUNC_START_ALIAS(alias2) ... asm insns ... SYM_FUNC_END(func) SYM_FUNC_END_ALIAS(alias1) SYM_FUNC_END_ALIAS(alias2) EXPORT_SYMBOL(alias1) EXPORT_SYMBOL(alias2) ... can become: SYM_FUNC_START(name) ... asm insns ... SYM_FUNC_END(name) SYM_FUNC_ALIAS(alias1, func) EXPORT_SYMBOL(alias1) SYM_FUNC_ALIAS(alias2, func) EXPORT_SYMBOL(alias2) This avoids repetition and hopefully make it easier to ensure consistency (e.g. so each function has a single canonical name and associated metadata). I'm sending this as an RFC since I want to check: a) People are happy with the idea in principle. b) People are happy with the implementation within <linux/linkage.h>. ... and I haven't yet converted the headers under tools/, which is largely a copy+paste job. I've build+boot tested arm64 and x86 defconfig without issues, and I've pushed the series to my `linkage/alias-rework` branch on git.kernel.org, atop v5.16-rc3: git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git linkage/alias-rework https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=linkage/alias-rework Thanks, Mark. Mark Rutland (6): linkage: add SYM_{ENTRY,START,END}_AT() linkage: add SYM_FUNC_{LOCAL_,}ALIAS() arm64: remove __dma_*_area() aliases arm64: clean up symbol aliasing x86: clean up symbol aliasing linkage: remove START/END ALIAS macros Documentation/asm-annotations.rst | 11 ++-- arch/arm64/include/asm/linkage.h | 24 --------- arch/arm64/kvm/hyp/nvhe/cache.S | 5 +- arch/arm64/lib/clear_page.S | 5 +- arch/arm64/lib/copy_page.S | 5 +- arch/arm64/lib/memchr.S | 5 +- arch/arm64/lib/memcmp.S | 6 +-- arch/arm64/lib/memcpy.S | 21 ++++---- arch/arm64/lib/memset.S | 12 +++-- arch/arm64/lib/strchr.S | 6 ++- arch/arm64/lib/strcmp.S | 6 +-- arch/arm64/lib/strlen.S | 6 +-- arch/arm64/lib/strncmp.S | 8 +-- arch/arm64/lib/strnlen.S | 6 ++- arch/arm64/lib/strrchr.S | 5 +- arch/arm64/mm/cache.S | 59 +++++++++----------- arch/x86/boot/compressed/head_32.S | 3 +- arch/x86/boot/compressed/head_64.S | 3 +- arch/x86/lib/memcpy_64.S | 10 ++-- arch/x86/lib/memmove_64.S | 4 +- arch/x86/lib/memset_64.S | 6 +-- include/linux/linkage.h | 86 ++++++++++++++++++------------ 22 files changed, 146 insertions(+), 156 deletions(-)