workflows.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Simon Horman <horms@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Alexandre Ferrieux <alexandre.ferrieux@gmail.com>,
	netdev@vger.kernel.org, workflows@vger.kernel.org,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH net] docs: netdev: Document guidance on inline functions
Date: Tue, 4 Feb 2025 22:46:12 +0000	[thread overview]
Message-ID: <20250204224612.766689a1@pumpkin> (raw)
In-Reply-To: <874j1bt6mv.fsf@trenco.lwn.net>

... 
> > +Inline functions
> > +----------------
> > +
> > +The use of static inline functions in .c file is strongly discouraged
> > +unless there is a demonstrable reason for them, usually performance
> > +related. Rather, it is preferred to omit the inline keyword and allow the
> > +compiler to inline them as it sees fit.
> > +
> > +This is a stricter requirement than that of the general Linux Kernel
> > +:ref:`Coding Style<codingstyle>`  
> 
> I have no objection to this change, but I do wonder if it does indeed
> belong in the central coding-style document.  I don't think anybody
> encourages use of "inline" these days...?


Apart from the cases where the compiler really ought to inline something
but fails to do so because it doesn't notice just how much code collapses
out.
But in that case you need always_inline.

For instance get_sigset_argpack (fs/select.c) is marked inline but isn't
being inlined by gcc 12.2 (clang 18 is inlining it).

I've also seen places where #defines generate much better code than
inline functions because they get processed much earlier.

	David

  parent reply	other threads:[~2025-02-04 22:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-03 13:59 Simon Horman
2025-02-03 15:00 ` Jonathan Corbet
2025-02-03 19:50   ` Mauro Carvalho Chehab
2025-02-03 19:53     ` Mauro Carvalho Chehab
2025-02-04 11:55       ` Simon Horman
2025-02-04 11:54     ` Simon Horman
2025-02-04 13:25       ` Andrew Lunn
2025-02-04 20:07         ` Simon Horman
2025-02-04 22:46   ` David Laight [this message]
2025-02-03 15:10 ` Andrew Lunn
2025-02-04  9:35   ` Simon Horman
2025-02-03 18:51 ` Randy Dunlap
2025-02-04 11:56   ` Simon Horman

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=20250204224612.766689a1@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=alexandre.ferrieux@gmail.com \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=workflows@vger.kernel.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