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

From: Mark Rutland <mark.rutland@arm.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-kernel@vger.kernel.org, Borislav Petkov <bp@alien8.de>,
	Jiri Slaby <jslaby@suse.cz>, Josh Poimboeuf <jpoimboe@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	ardb@kernel.org, broonie@kernel.org, dave.hansen@linux.intel.com,
	linux-arm-kernel@lists.infradead.org, maz@kernel.org,
	mingo@redhat.com, tabba@google.com, tglx@linutronix.de,
	will@kernel.org
Subject: Re: [RFC PATCH 0/6] linkage: better symbol aliasing
Date: Wed, 15 Dec 2021 09:24:22 +0000	[thread overview]
Message-ID: <Ybm0Rl6TxdgA0tsB@FVFF77S0Q05N> (raw)
In-Reply-To: <YbNsjU2n2uXlg3fc@arm.com>

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel