[EMAIL PROTECTED] 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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
