At a high enough level of optimization, I think it will do so.  Properly
scoping functions static that do not need global scope is probably a big
assist to the compiler in this regard.  Unfortunately, I think a lot of
developers don't understand the importance of reducing symbols with
external scope to just those that are truly necessary.

(Solaris has a DDI compliance test that includes a check for this for
kernel developers.  It might not be a bad idea to have a similar
automated test ourselves.  This would also go a long way towards
defining a true kernel API, since a predefined list of functions that
must be global in scope needs to be created.)

I also find in general that there is a lot of duplication of effort in
various ports of NetBSD, with different approaches for achieving
essentially the same thing.  The different approaches for bus_space
routines are a good example, where for some ports the functions are
macros that dereference function pointers whereas for others they are
true functions.  Having a true DDI/Kernel API would almost force that
bit to get cleaned up.

Take a look at the opensolaris version of ddi_get[8,16,32] or DMA
mapping support to see what I'm talking about.

(The only possible drawback here being that you might incur additional
function call overhead for some platforms that currently use macros for
some core stuff.  But the flexibility gains would probably outweigh this.)

    -- Garrett

Jed Davis wrote:

>Thor Lancelot Simon <tls@rek.tjls.com> writes:
>
>  
>
>>On Sun, Nov 20, 2005 at 08:01:26PM +0000, David Laight wrote:
>>    
>>
>>>Inlining code can have a large negative performance due to the way
>>>that it interacts rather badly with the instruction cache.
>>>      
>>>
>>I think we're very much in agreement about this.  Just to be clear, I am
>>suggesting that we *first* move from macros to inline functions -- a
>>change that is primarily syntactic, which should have little or no impact
>>on performance but improve readability and maintainability of code, *then*
>>carefully consider which of those functions should be inline at all: any
>>resulting changes at that point should be much simpler to make because
>>the macros will have already been converted to function form.
>>    
>>
>
>It Would Be Nice If the compiler could attempt to decide on its own
>whether a particular function should be inlined, since it's likely to
>know more about the situation on a given architecture than we do.
>
>  
>


-- 
Garrett D'Amore                          http://www.tadpolecomputer.com/
Sr. Staff Engineer          Extending the Power of 64-bit UNIX Computing
Tadpole Computer, Inc.                             Phone: (951) 325-2134