lkml.org 
[lkml]   [2021]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 0/6] linkage: better symbol aliasing
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.

\
 
 \ /
  Last update: 2021-12-15 10:24    [W:0.082 / U:0.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site