On Fri, 19 Jan 2007, Adrian Bunk wrote: > On Fri, Jan 19, 2007 at 11:56:30AM -0500, Robert P. J. Day wrote: > > > > Remove the macros that define simple "inlining" to mean forced > > inlining, since you can (and *should*) get that effect with the > > CONFIG_FORCED_INLINING kernel config variable instead. > > NAK. > > I don't see any place in the kernel where we need a non-forced > inline.
that's not the point. the point is that, as it stands now, the build is *broken* in three ways. first, it's broken because declaring something simply as "inline" *forces* it to be inlined, which flies in the face of historical convention and is more than a little misleading. second, it's broken because both the use of "__attribute__((always_inline))" all over the place and the CONFIG_FORCED_INLINING kernel config option imply that you indeed have a choice, when you clearly *don't*. quite simply, you can play with that kernel config option or splash the "always_inline" attributes around all you want and, unbeknownst to you, none of that is making the *slightest* bit of difference. that is the very *definition* of a "broken" build. and, finally, you claim that you "don't see any place in the kernel where we need a non-forced inline." i have already posted an alpha header file that claims (rightly or wrongly) to need that freedom. Q.E.D. > We have tons of inline's in C files that should simply be removed - > let's do this instead. that may be a better idea, but it doesn't address the current brokenness. i'm willing to believe that this patch has zero chance of going anywhere. but if you want to reject it, at least be honest about it. don't say, "there's no problem here." instead, say, "yes, the build is broken but we don't feel like doing anything about it." 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/
