>>> [long jumps for LKMs]
>> Would it be possble to simply have all code in the low 32 Mb of the
>> virtual address space for the kernel?
>
>In principle, yes.  In practice...well, it would mean 
>
>Here's what I found when I investigated, which was a while ago.  Some
>aspects of it may have changed, some probably haven't.
>
>The kernel is read into low physical memory, and all physical memory is
>mapped with BAT0, so virtual==physical.  (This means no more than 256M
>physical memory.)  The kernel is linked expecting itself to live at low
>virtual addresses, and runs out of the virtual space mapped by BAT0.
>
>When the kernel needs to dynamically allocate space, it allocates it
>out of the space mapped by SR14, 0xe0000000-0xefffffff, setting up page
>tables to point to the relevant physical pages (which are already
>mapped by BAT0 at different addresses; LKMs can't simply go in low VM
>because (1) it may not be possible to find physically contiguous memory
>and (2) if you can, it may be >32M away from the kernel, if the machine
>has >32M of RAM).
>
>In principle, you could shuffle physical pages to get contiguous
>physical memory immediately after the kernel, then load the LKM there.
>But this would mean a separate memory allocator just for LKMs, not to
>mention the physical page shuffling issues.

SMOP. ;->

(I figured there must be a reason.)

-dgl-