* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Sat, 10 Jan 2009, Ingo Molnar wrote: > > > > Well, it's not totally meaningless. To begin with, defining 'inline' to > > mean 'always inline' is a Linux kernel definition. So we already changed > > the behavior - in the hope of getting it right most of the time and in the > > hope of thus improving the kernel. > > Umm. No we didn't. We've never changed it. It was "always inline" back in s/changed the behavior/overrode the behavior > the old days, and then we had to keep it "always inline", which is why > we override the default gcc meaning with the preprocessor. > > Now, OPTIMIZE_INLINING _tries_ to change the semantics, and people are > complaining.. But i'd definitely argue that the Linux kernel definition of 'inline' was always more consistent than GCC's. That was rather easy as well: it doesnt get any more clear-cut than 'always inline'. Nevertheless the question remains: is 3% on allyesconfig and 1% on defconfig (7.5% in kernel/built-in.o) worth changing the kernel definition for? I think it is axiomatic that improving the kernel means changing it - sometimes that means changing deep details. (And if you see us ignoring complaints, let us know, it must not happen.) So the question isnt whether to change, the question is: does the kernel get 'better' after that change - and could the same be achieved realistically via other means? If you accept us turning all 30,000 inlines in the kernel upside down, we might be able to get the same end result differently. You can definitely be sure if people complained about this ~5 lines feature they will complain about a tens of thousand of lines patch (and the followup changed regime) ten or hundred times more fiercely. And just in case it was not clear, i'm not a GCC apologist - to the contrary. I dont really care which tool makes the kernel better, and i wont stop looking at a quantified possibility to improve the kernel just because it happens to be GCC that offers a solution. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
