[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: GNU vs C99 extern inline
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()
> 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
It doesn't look to me like we need the "extern inline" idiom.
David Young OJC Technologies
dyoung%ojctech.com@localhost Urbana, IL * (217) 344-0444 x24
Main Index |
Thread Index |