On Thu, Feb 06, 2003 at 03:25:15PM -0800, Greg KH wrote:
> Come on, what Rusty did was the "right thing to do" and has made life
> easier for all of the arch maintainers (or so says the ones that I've
> talked to)
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
this option.
(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 (rmk@arm.linux.org.uk) 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 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/
This archive was generated by hypermail 2b29 : Fri Feb 07 2003 - 22:00:22 EST