Re: [PATCH] asm-generic: replace ________addr with __UNIQUE_ID(addr)

[Andrew Morton]

On Sun, 26 Apr 2026 11:49:38 +0100 David Laight <david.laight.linux@xxxxxxxxx> wrote:

> On Sat, 25 Apr 2026 15:12:40 -0700
> Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > On Sat, 25 Apr 2026 23:01:34 +0100 David Laight <david.laight.linux@xxxxxxxxx> wrote:
> > 
> > > > > The real problem with this define is that both idx and phys are
> > > > > expanded twice.    
> > > > 
> > > > The real problem with this define is that it's a define.  Why oh why do
> > > > we keep doing this to ourselves?  
> > > 
> > > Sometimes #defines generate better code because they are expanded earlier,
> > > and sometimes you want type-agnostic 'functions'.
> > > But neither is true here.
> > > 
> > > But I think I'd go for 'always_inline'.
> > > Sometimes the compilers make silly decisions.  
> > 
> > Gee, if `static inline' misbehaves then we have big problems!
> > 
> > What's special about the fixmap code anyway?  It's not exactly
> > fastpath.  Perhaps this stuff can simply be uninlined.
> 
> Some of the inlines are trivial - just adding an extra parameter.
> But this set would be simpler if the last function
> (__native_set_fixmap() for x86) returned (address & ~PAGE_MASK)

I don't understand this?

> > 
> > Pet peeves:
> > 
> > We use too many macros.
> 
> Indeed, I get fed up of looking things up to find they are trivial.
> Some of the 'helpers' do nothing for core readability.
> Even things like BIT() can have unexpected consequences.

Sure.

> Not to say I haven't got the pre-processor to do odd things in the past.
> But it is usually trying to avoid having to keep multiple definitions
> aligned with each other.
> 
> > We inline too much stuff.
> 
> True - don't look at what strlcpy() can generate.
> The inline code should just get the constants from the compiler and
> then call the appropriate function.

I can't actually find an in-kernel strlcpy()?

> As does the compiler.
> pixpaper_panel_hw_init() repeatedly calls two static functions that
> contain sleeps. They all get inlined bloating the code size and
> exploding the stack when clang separately allocates all the buffers
> in the called functions.

Poor thing.  I guess compiler developers are more focused on userspace
code and aren't especially concerned about kernel's particular
requirements.  And that's understandable - it's down to us to persuade
them to add options to permit us to tune the compiler behavior.