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 [email protected] Urbana, IL * (217) 344-0444 x24
