* Adrian Bunk <bunk@xxxxxxxxxx> wrote: > are the result of a quick Google search of me stating this previously on > linux-kernel. It might have been more often, but I'm too lame too > search further. > > http://lkml.org/lkml/2007/1/19/36 that's a side-note, not a bugreport and not a patch to fix it. > http://lkml.org/lkml/2007/4/9/363 this second one is this very thread that i replied to. > > no, what we should nuke is this always_inline definition. That was > > always the intention of FORCED_INLINE, and the removal of > > FORCED_INLINE was to _remove the forcing_, not to make it > > unconditional. > > It was always unconditional, and neither adding, toggling nor removing > of CONFIG_FORCED_INLINING changed this invariant. > > And what we should do is to attack the excessive wrong usage of > inlines in .c files, not messing with a global #define in a way that > the results on 24 architectures with 7 different releases of gcc would > be unpredictable. i see, so you never properly reported and fixed it because you prefer a 1000 small crappy changes over one change. You could have significantly contributed to truly making Linux smaller, but you decided not to do it. and i disagree with your notion that flipping it around is risky in any unacceptable or unmanageable way. It has far less risks on the compiler than say CONFIG_CC_OPTIMIZE_FOR_SIZE. It has far less risks than changing to a new compiler version. Why you think it's "unpredictable" is a mystery to me. It almost seems to me you were happy with having that bug in the kernel? Please tell me that i'm wrong about that impression! i'll reinstate this .config option and let it do the right thing. Forced inlining was supposed to be _phased out_, not phased in. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
