> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > I *have* had problems with -fno-inline. I'd very much like > to be able to turn that on, but the presence of `extern inline' > functions causes a link failure with `-fno-inline'. > > Feel free to submit the patch that converts the remaining extern > inline into static inline. That is the correct solution. > > GCC has every right not to inline and expect the function name to be > referencable externally if you say extern inline, so this is another > reason to fix the remaining extern inline instances. > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > Does this imply that it is ALWAYS better to use "static inline" instead of > "extern inline"? According to this: > > http://linux-study.cs.ccu.edu.tw/HyperNews/get/gcc/2.html > > "extern inline is almost always the wrong thing". > > So should the kernel source be changed to read "static inline" everywhere > where it used to be "extern inline"? AFAIK static inline is defined "inline and if you can't, crate static version". OTOH extern inline is defined "inline and if you can't, expect external definition". Ie. there are two ways to go. Have a static inline definition in a header, or have an extern inline definition in header AND normal definition in some source! The second doesn't sound too useful. -------------------------------------------------------------------------------- - Jan Hudec `Bulb' <bulb@ucw.cz> -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
