Re: [2.6 patch] kill __always_inline

[Adrian Bunk <bunk@fs.tum.de>]

On Tue, Aug 31, 2004 at 03:36:49PM -0700, Andrew Morton wrote:
> Adrian Bunk <bunk@fs.tum.de> 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 
time.

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


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?


cu
Adrian

-- 

       "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