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 :)