Subject: Re: Any resolution for LKM issues?
To: Wolfgang Solfrank <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 03/16/2001 10:20:15
On Fri, 16 Mar 2001, Wolfgang Solfrank wrote:
> Minor nit: it's segment 0 for the kernel code and segment E for LKMs.
Ahhh.. Thanks. I forgot exactly which ones it was. I knew they were more
than 32 MB apart.
> Well, yes, that's an unfortunate side effect of the ppc kernel layout:
> While running kernel code, all but segments D & E are mapped 1:1 between
> virtual and real addresses. This mapping is totally invisible to uvm.
> The kernel text/data/bss isn't part of what memory management calls
> "kernel virtual memory", i.e. the address range accessible by kernel
> virtual addresses known to uvm (which happens to be in segment E).
> The kernel itself just happens to live somewhere in low core and due to
> the above 1:1 mapping can be accessed easily. Any real memory that
> isn't occupied by the kernel is managed by uvm, so we cannot easily
> allocate contiguous real memory that is close enough to the kernel.
> Therefore (and in order to avoid implementing a totally different LKM
> loading scheme) LKMs are allocated in the E segment (just as any other
> memory that is allocated by the kernel).
Unfortunatly that means that we MUST change the toolchain to get them to
> Hope this explains things a bit.
> PS: If you wondered about segment D in the above, it is used to
> access user virtual memory during copyin/copyout and friends.