Messages in this thread | | | Subject | Re: [PATCH] Restore module support. | Date | Fri, 7 Feb 2003 10:43:19 -0800 | From | "Luck, Tony" <> |
| |
> (2) has the disadvantage that its touching non-architecture specific > code, but this is the option I'd prefer due to the obvious performance > advantage. However, I'm afraid that it isn't worth the effort to fix > up vmalloc and /proc/kcore. vmalloc fix appears simple, but /proc/kcore > has issues (anyone know what KCORE_BASE is all about?)
KCORE_BASE is my fault ... it was an attempt to fix the "modules below PAGE_OFFSET" problem for the ia64 port. For a few nanoseconds the code just here looked like this:
#if VMALLOC_START < PAGE_OFFSET #define KCORE_BASE VMALLOC_START #else #define KCORE_BASE PAGE_OFFSET #endif
Which worked great for ia64, but failed to even compile on i386 (because on i386 VMALLOC_START isn't a simple constant that cpp can compare against).
Linus kept the bulk of my patch and just replaced the above code with the "#define KCORE_BASE PAGE_OFFSET" that is there today, maybe in the hope that I'd come back with a workable #ifdef ... but the only one I've come up with so far is "#ifdef CONFIG_IA64" which can't be right as ia64 isn't the only architecture with this issue.
There was some discussion on a better way to do this, by adding the kernel itself to the vmlist, and eliminating all the special case code. I took a brief look at this, but realised that there were all sorts of ugly race conditions with /proc/kcore if a module is loaded/unloaded after some process has read the Elf header.
-Tony Luck
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |