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

Besides, if you load multiple large LKMs, it strikes me as not
impossible that your total text segment is >32M, in which case you have
problems no matter where you put stuff (though admittedly, as you point
out, this is probably not a very big deal).

As someone else pointed out, making ld do the stubs is semi-necessary
anyway in order to be able to link programs with >32M of text, and thus
needs to be done eventually.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B