Re: [RFC PATCH 0/6] linkage: better symbol aliasing

[Mark Rutland]

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@xxxxxxx/

... 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.