'static inline' vs macros for kernel functions ? (was how to handle name clashes in linux/freebsd kernel sources ?)

This is related to the post attached at the end of this email.

In this commit:

    CVS log for src/sys/sys/systm.h
    Revision 1.252: download - view: text, markup, annotated - select for diffs
    Fri Mar 9 22:41:01 2007 UTC (3 months, 2 weeks ago) by jhb

msleep() changed from a function to a macro wrapping _sleep().

Being a macro, it is a lot harder to hide it in case of name clashes
such as the one mentioned below.

This raises the question - what is the point in using macros
in cases like this where we could use static inline function and
probably even exploit better compiler checks ?

Would it be possible to revert msleep() to a real function ?

	cheers
	luigi

On Tue, Jun 26, 2007 at 04:07:58AM -0700, Luigi Rizzo wrote:
> hi,
> as part of the linux-kmod-compat code, and also SoC-KVM work,
> we are integrating some linux kernel source code with FreeBSD source,
> and there are a number of clashes in names (macros, functions, etc.)
> used in different ways in the two camps.
> 
> Any ideas on how to handle the conflict ? As a temporary workaround we 
> added a _compat suffix (in the source code) to the linux names,
> but this is of course undesirable, especially for widely used names.
> 
> E.g. take these two examples:
> 
> msleep() - used to be a function in FreeBSD 6.x, but now it is a macro    
> 
>   when it was a function we could make the linux source do the following
>         #include <sys/systm.h>          // bring in the prototype
>         #define msleep  linux_msleep    // override for linux source
>         // now reinclusion of sys/systm.h won't give problems
>   and then implement the linux function. However this breaks with
>   FreeBSD macros that call msleep, because they will be expanded using
>   linux msleep.
> 
>   With the macro version, we have not found a solution yet.
> 
> list manipulation macros
>   these have the same names on linux and FreeBSD, but different
>   arguments, so they are not compatible. Here the redefinition through
>   a macro won't even work.
> 
> So... any ideas on how to handle this, short of renaming the linux
> macros ?
> 
> 	cheers
> 	luigi