From: Peter Zijlstra <peterz@infradead.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Borislav Petkov <bp@alien8.de>,
namit@vmware.com, Joe Perches <joe@perches.com>,
segher@kernel.crashing.org, Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC][PATCH] tree-wide: Remove __inline__ and __inline usage
Date: Tue, 6 Nov 2018 15:46:19 +0100 [thread overview]
Message-ID: <20181106144619.GB9781@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CANiq72=VUEvPJf_U8s+FJbdj7pbEpsxepFaduUoW7Ov_arnRGA@mail.gmail.com>
On Tue, Nov 06, 2018 at 03:09:37PM +0100, Miguel Ojeda wrote:
> On Tue, Nov 6, 2018 at 11:02 AM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > allows adding the "inline" keyword to 'asm ("")' statements. The
> > problem is that we're possibly redefining "inline" to
> > "inline __attribute__((__always_inline__))" which makes the proposed:
> >
> > asm volatile inline ("")
> >
> > (...)
> >
> > -#define inline inline
> > -#define inline inline
> > -
>
> It seems somehow your patch got underscores removed.
If you actually read what I wrote:
> > Therefore I'm proposing to run:
> >
> > git grep -l "\<__inline\(\|__\)\>" | while read file
> > do
> > sed -i -e 's/\<__inline\(\|__\)\>/inline/g' $file
> > done
> >
> > On your current tree, and apply the below fixup patch on top of that
> > result.
It makes sense.
> By the way, we have been re#defining the inline keyword since (at
> least) 2003, and already in 2008 Ingo was commenting in a commit to
> add the #ifdef to avoid it for x86. Is it still a good idea nowadays
> that the minimum compiler is quite modern compare to a decade ago? Is
> it still needed on non-x86 arches (they don't have it in the
> defconfig)? Couldn't functions be marked as __always_inline if really
> needed (as many are)?
>
> By the way (x2): CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING is only ever
> referenced in that #ifdef. May it be removed?
Dunno, but that is a far more difficult patch. The proposed one is an
obvious identify.
next prev parent reply other threads:[~2018-11-06 14:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-06 10:02 Peter Zijlstra
2018-11-06 14:09 ` Miguel Ojeda
2018-11-06 14:46 ` Peter Zijlstra [this message]
2018-11-06 17:21 ` Miguel Ojeda
2018-11-06 19:18 ` Linus Torvalds
2018-11-06 19:41 ` Peter Zijlstra
2018-11-06 19:51 ` Linus Torvalds
2018-11-06 19:59 ` Peter Zijlstra
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=20181106144619.GB9781@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bp@alien8.de \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=mingo@kernel.org \
--cc=namit@vmware.com \
--cc=segher@kernel.crashing.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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
all inboxes | Powered by JetHome®