Re: Query on remap_pfn_range compatibility

From: Timur Tabi
Date: Tue Jan 25 2005 - 13:16:52 EST


Mark_H_Johnson@xxxxxxxxxxxx wrote:


I am also trying to avoid an ugly hack like the following:

VMA_PARAM_IN_REMAP=`grep remap_page_range
$PATH_LINUX_INCLUDE/linux/mm.h|grep vma`
if [ -z "$VMA_PARAM_IN_REMAP" ]; then
export REMAP_PAGE_RANGE_PARAM="4"
else
export REMAP_PAGE_RANGE_PARAM="5"
endif

My makefile has a ton of stuff like this. Our driver needs to work with all 2.4 and 2.6 kernels, and it makes heavy use of the VM. It also needs to deal with distros that have "broken" header files.

This wouldn't be such a problem if the kernel developers would add macros to indicate the version of the function parameters. Basically, the header file should define REMAP_PAGE_RANGE_PARAM (or some equivalent), so that you don't need to calculate it in your makefile. But the kernel developers don't care about backwards compatibility, so we're stuck with these ugly hacks.

Would it be acceptable to add a symbol like
#define MM_VM_REMAP_PFN_RANGE
in include/linux/mm.h or is that too much of a hack as well?

The easiest solution would be to update gcc to provide some kind of internal macro that would tell me if a function is defined or not. For instance, I could do this:

#if defined(remap_pfn_range)
remap_pfn_range(...)
#else
remap_page_range(...)
#endif

This doesn't work because remap_pfn_range is a function, not a macro. Then we could do other things like:

#if parameters(remap_page_range) = 4
remap_page_range(a, b, c, d)
#else
remap_page_range(a, b, c, d, e)
#endif

This would allow me to handle kernel versions that have 4 instead of 5 parameters for remap_page_range().

Ironically, even if gcc were updated like this, it wouldn't help me a whole lot, because I still need to use the older versions of gcc on the older distros. But at least it the problem wouldn't be getting worse, like it is today.

--
Timur Tabi
Staff Software Engineer
timur.tabi@xxxxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/