On Sat, 10 Jan 2009 02:01:25 +0100 Ingo Molnar <mi...@elte.hu> wrote:
> > * Linus Torvalds <torva...@linux-foundation.org> wrote: > > > On Sat, 10 Jan 2009, Ingo Molnar wrote: > > > > > > may_inline/inline_hint is a longer, less known and uglier keyword. > > > > Hey, your choice, should you decide to accept it, is to just get rid of > > them entirely. > > > > You claim that we're back to square one, but that's simply the way > > things are. Either "inline" means something, or it doesn't. You argue > > for it meaning nothing. I argue for it meaning something. > > > > If you want to argue for it meaning nothing, then REMOVE it, instead of > > breaking it. > > > > It really is that simple. Remove the inlines you think are wrong. > > Instead of trying to change the meaning of them. > > 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. > > And now it appears that in our quest of improving the kernel we can > further tweak that (already non-standard) meaning to a weak "inline if the > compiler agrees too" hint. That gives us an even more compact kernel. It > also moves the meaning of 'inline' closer to what the typical programmer > expects it to be - for better or worse. > > We could remove them completely, but there are a couple of practical > problems with that: > > - In this cycle alone, in the past ~2 weeks we added another 1300 inlines > to the kernel. Who "reviewed" all that? > Do we really want periodic postings of: > > [PATCH 0/135] inline removal cleanups > > ... in the next 10 years? We have about 20% of all functions in the > kernel marked with 'inline'. It is a _very_ strong habit. Is it worth > fighting against it? A side-effect of the inline fetish is that a lot of it goes into header files, thus requiring that those header files #include lots of other headers, thus leading to, well, the current mess. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
