On Fri, 19 Jan 2007, Adrian Bunk wrote: > With the current implementation in the kernel (and considering that > CONFIG_FORCED_INLINING was implemented in a way that it never had > any effect), __always_inline and inline are currently equivalent.
yes, that option was implemented in a half-assed sort of way. if you look at compiler-gcc4.h, at first glance the preprocessing looks like it's doing the right thing for that config option: ================================== #include <linux/compiler-gcc.h> #ifdef CONFIG_FORCED_INLINING # undef inline # undef __inline__ # undef __inline # define inline inline __attribute__((always_inline)) # define __inline__ __inline__ __attribute__((always_inline)) # define __inline __inline __attribute__((always_inline)) #endif ================================== but it's too late for checking that kernel config option, since compiler-gcc.h has already been included, which includes: ================================== #define inline inline __attribute__((always_inline)) #define __inline__ __inline__ __attribute__((always_inline)) #define __inline __inline __attribute__((always_inline)) ================================== so, as you say, "__always_inline and inline are currently equivalent". which is sort of confusing and might come as a nasty surprise to some developers who weren't expecting that. rday - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
