On Wed, 12 Jun 2002, Rusty Russell wrote:
>
> The only really sane way to implement "CONFIG_SMALL_NO_INLINES" that I
> can think of is to have headers do
inlines, when used properly, are _not_ larger than not inlining.
Quite often, inlining means that much of the code goes away due to
constants etc (alloc_pages(), for example), while in other cases the code
itself ends up being smaller because a small function takes up space due
to clobbering registers, memory, and all the function calling sequence
itself.
This is _very_ much the case with the list.h inlines we're talking about.
They'd be larger, slower, and the resulting assembly code would be less
readable if they weren't inlined.
However, we do have some inlines that are just too large, and have often
grown up over time. They should not be a CONFIG_SMALL_NO_INLINES thing,
though, they should just be moved into proper .c file.s
(There are also inlines that _look_ large, but which just go away when
attacked by an optimizing compiler. See all the "get_user()" stuff with
case statements etc)
None of these ugly header file tricks, please.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:24 EST