On Mon, 28 Apr 2008, Thomas Gleixner wrote:Thanks for checking. In general, I think we should act the other way: we should *assume* that inlines and complex macros in header files are not worth it and we'd be better off with just plain function calls, unless it's really obvious that the inline function is always worth it. We have tons of good examples of inline functions in headers that really *really* want to be that way: <linux/list.h> is generally a collection of things that clearly expand to somthing that is (a) easily critical and (b) inlining things generally really causes a smaller code footprint than having a "call" instruction and all the argument setup - regardless of how many times it is done. So we do have cases where the inlines are obviously worth it. But in general, I think we should try to move things from the header files into *.c files unless there is a really clear reason for keeping it that way. (Some inline functions do depend on things like constant arguments goign away, with kmalloc() being a good example of some really nasty header file tricks that are likely worth it despite their extreme ugliness) Linus --
| Hiten Pandya | Re: up? (emacs docbook xml ide) |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Roland Dreier | Re: Integration of SCST in the mainstream Linux kernel |
| Florian Schmidt | blacklist kernel boot option |
git: | |
| Linus Torvalds | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
| Arjan van de Ven | Re: [GIT]: Networking |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
