Messages in this thread | | | Date | Wed, 1 Sep 2004 00:52:44 +0200 | From | Adrian Bunk <> | Subject | Re: [2.6 patch] kill __always_inline |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |