It is for user-space developers who include headers for the ksyms
prototypes. It works to permit them to use gcc -ansi and -pedantic if they
wish. I recommend that for producing maintainable and portable code.
$ info gcc;
for reasons to use __inline__. I didn't invent that macro, you know. The
majority of kernel headers used it to start with.
>it would need to be reserved for C++ compatibility anyways.
>Near all interesting (=optimizing) C compilers know about inline, and if
>not it can be easily #define'd out. Also the next revision of the C
>standard has inline.
Who's going to put the revisions into gcc-2.7.2?
>
>What they usually don't deal with is gcc's "extern inline", so
>migrating from "extern inline" to "static inline". The reasoning behind
Yes, I think that may need to be handled, perhaps by something like:
#ifdef _GNUC_
extern
#endif
I'm open to suggestions on that.
>the extern thing seems to be to let ld catch non inlined copies. A much
>better way to archieve this IMHO is -Winline (if you can stand the few
>warnings for the non-fixable cases - which should be few because with
>extern inline they didn't even compile)
>
>I think the kernel header ANSIfication is a doomed project though, because
>how do you do a efficient spinlock without inline assembly (and don't say
>now "move it out of line")? In 2.2+ you cannot do much without spinlocks.
>In 2.0 the same applies e.g. to cli/sti
>
Who said anything about altering kernel mechanisms for this?
I think you haven't followed the discussion that produced these patches. I
would have turned off the religious war too, if I hadn't got involved as an
innocent agnostic.
>
>-Andi
Tom
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/