From: David Laight <david.laight.linux@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Min-Hsun Chang <chmh0624@gmail.com>,
arnd@arndb.de, msalter@redhat.com, linux-arch@vger.kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] asm-generic: replace ________addr with __UNIQUE_ID(addr)
Date: Sun, 26 Apr 2026 11:49:38 +0100 [thread overview]
Message-ID: <20260426114938.4dff28c8@pumpkin> (raw)
In-Reply-To: <20260425151240.2a46e3a8640fde3902461d41@linux-foundation.org>
On Sat, 25 Apr 2026 15:12:40 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Sat, 25 Apr 2026 23:01:34 +0100 David Laight <david.laight.linux@gmail.com> 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)
>
> 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.
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.
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.
David
next prev parent reply other threads:[~2026-04-26 10:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-07 9:21 [PATCH] asm-generic: replace ________addr with __UNIQUE_ID(addr) Min-Hsun Chang
2026-03-22 13:20 ` Min-Hsun Chang
2026-03-22 14:40 ` David Laight
2026-04-25 20:57 ` Andrew Morton
2026-04-25 22:01 ` David Laight
2026-04-25 22:12 ` Andrew Morton
2026-04-26 10:49 ` David Laight [this message]
2026-04-26 11:09 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260426114938.4dff28c8@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=chmh0624@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=msalter@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox