Hi,

> The second part of the problem is that the kernel gets mapped in segment E
> (0xExxxxxxx), but the LKMs want to get loaded somewhere else (like segment
> 2, 0x2xxxxxxx) I believe.

Minor nit: it's segment 0 for the kernel code and segment E for LKMs.

> The only other thing I can think of, which I'd like some input on from
> folks more familiar with the ppc kernel layout, is to try to link LKMs in
> in the top of the "D" segment. Like starting at 0xdfffffff and working
> down. I mean our kernels aren't THAT big (I think 3MB to 4 MB is typical),
> so all of the kernel should be within 32 MB of the top of the D segment.

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).

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.

Ciao,
Wolfgang
-- 
ws@TooLs.DE     Wolfgang Solfrank, TooLs GmbH 	+49-228-985800