tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

GNU vs C99 extern inline



Hi

returning to GNUC vs C99 semantics for inline functions, this is now
partly handled with a __c99inline keyword but there are several files in
the kernel containing functions marked inline that yet require external
linkage as they are also called from other source modules..  this is
provided by the opposite of __c99inline in both the GNUC and C99 cases, as
per the patch below which adds an __extinline keyword for this usage

Index: cdefs.h
===================================================================
RCS file: /cvsroot/src/sys/sys/cdefs.h,v
retrieving revision 1.84
diff -u -r1.84 cdefs.h
--- cdefs.h     19 Feb 2011 02:21:21 -0000      1.84
+++ cdefs.h     30 Mar 2011 20:50:58 -0000
@@ -277,10 +277,13 @@
  */
 #if defined(__GNUC__) && defined(__GNUC_STDC_INLINE__)
 #define        __c99inline     extern __attribute__((__gnu_inline__)) __inline
+#define        __extinline     extern __inline
 #elif defined(__GNUC__)
 #define        __c99inline     extern __inline
+#define        __extinline     __inline
 #elif defined(__STDC_VERSION__)
 #define        __c99inline     __inline
+#define        __extinline     extern __inline
 #endif

 #if defined(__lint__)

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)

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.

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

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

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..

thoughts?
iain

just as an aside, this is the last outstanding issue that prevents pcc
from building an i386 NetBSD kernel (though, there is more work to be
done as the kernel that I managed to build fails to boot :)



Home | Main Index | Thread Index | Old Index