'static inline' vs macros for kernel functions ? (was how to handle
name clashes in linux/freebsd kernel sources ?)
rizzo at icir.org
Tue Jun 26 19:31:31 UTC 2007
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 ?
On Tue, Jun 26, 2007 at 04:07:58AM -0700, Luigi Rizzo wrote:
> 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 ?
More information about the freebsd-current