Re: GNU vs C99 extern inline

[David Young <dyoung%pobox.com@localhost>]

On Sat, Apr 16, 2011 at 09:27:41PM +0100, Iain Hibbert wrote:
> however, I'm not that enamoured of the name, and considering the following
> (mostly MI) instances that I have found:
> 
> 1. dev/ic/ad1848.c:ad_read()
>                  ad_write()
>                  ad_xread()
>                  ad_xwrite()
> 
>  these seem to be IO routines and should arguably be static inline,
>  defined in a header file (ad1848var.h perhaps, though there is some
>  trickery as they require definitions from a couple of other headers)

These seem to do (slow) I/O.  I don't think they need to be inline.

> 2. kern/kern_sleepq.c:sleepq_insert()
> 
>  The only place this is called aside from that file is compat_sa.c so its
>  probably a gross invasion of the API.

Probably a gross invasion.

> 3. arch/x86/x86/pmap.c:pmap_reference()
> 
>  this is the only arch with pmap_reference() function marked inline in
>  this way. If it is really performance critical then it could be defined
>  in x86/include/pmap.h directly so that uvm also gains from it

How about making it static inline in the header file?

> 4. kern/kern_descrip.c:fd_getfile()
> 
>  as this function seems quite large, inlining might not give that much
>  benefit, and most of the calls are using the external reference anyway

I agree that it's probably not beneficial.

> So, any ideas what is the best way forward for this concept, and these
> functions?   I guess I could commit the above (or something like) and
> convert the definitions, or I could work at removing the idiom
> altogether..

It doesn't look to me like we need the "extern inline" idiom.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 344-0444 x24