[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250204224612.766689a1@pumpkin>
Date: Tue, 4 Feb 2025 22:46:12 +0000
From: David Laight <david.laight.linux@...il.com>
To: Jonathan Corbet <corbet@....net>
Cc: Simon Horman <horms@...nel.org>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Alexandre Ferrieux
<alexandre.ferrieux@...il.com>, netdev@...r.kernel.org,
workflows@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATCH net] docs: netdev: Document guidance on inline functions
...
> > +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
Powered by blists - more mailing lists