And I'll promptly provide you with the other view. I'm still trying to
sort out the best thing to do for ARM. We have the choice of:
1. load modules in the vmalloc region and build two jump tables, one for
the init text and one for the core text.
2. fix vmalloc and /proc/kcore to be able to cope with a separate module
region located below PAGE_OFFSET. Currently, neither play well with
(1) has the advantage that it's all architecture code, its what we've
done with the old modutils, and I've finally managed to implement it.
However, it introduces an extra instruction and data cache line fetch
to branches from modules into the kernel text.
(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?)
I've not made up my mind which option I'm going to take. If I don't get
around to fixing /proc/kcore by this weekend, I'll probably just throw
option (1) at Linus, which bring Linus' tree back to a buildable state
for some ARM targets again.
-- Russell King (email@example.com) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/