[lkml]   [2004]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [2.6 patch] kill __always_inline
On Tue, Aug 31, 2004 at 03:36:49PM -0700, Andrew Morton wrote:
> Adrian Bunk <> wrote:
> >
> > An issue that we already discussed at 2.6.8-rc2-mm2 times:
> >
> > 2.6.9-rc1 includes __always_inline which was formerly in -mm.
> > __always_inline doesn't make any sense:
> >
> > __always_inline is _exactly_ the same as __inline__, __inline and inline .
> >
> >
> > The patch below removes __always_inline again:
> But what happens if we later change `inline' so that it doesn't do
> the `always inline' thing?
> An explicit usage of __always_inline is semantically different than
> boring old `inline'.

Who audits all current users of inline whether they are __always_inline?

Who ensures, that in the future there will always be the right one of
inline and __always_inline choosen in the kernel?

If it doesn't give a compile or runtime error for anyone when it's
wrong, many wrong inline/__always_inline will go into the kernel over

The intention might be a different semantics, but in the end, it won't

E.g., check how many wrong __init/__exit annotations show up in 2.6,
each of whom would have been a compile error in 2.4 (and different
from a wrong inline/__always_inline, a wrong __init/__exit annotation
can cause real problems for users).

If you want to change inline at some point, you will have to audit all
users of inline anyway - so why bother if you don't intend to change
inline in the forseeable future?



"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:05    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean