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

Actually, unless someone's changed something quite recently, kernel
text (and the rest of core) is mapped with BAT 0, not segment 0.

Not that it makes any difference from an addressing point of view; it
just means we can't juggle VM mappings to make physically noncontiguous
pages (a) contiguous and (b) within 32M of kernel text.

>> Unfortunatly that means that we MUST change the toolchain to get
>> them to work. :-(
> Actually, doesn't that mean that you just change the definition of
> the text (-T) address [...]?  I mean, couldn't you build the LKM and
> pass it -Ttext e0000000 or some such?

Sure you could, but it wouldn't help. :-)

The problem is that the LKM can't call routines in kernel text unless
either (a) the LKM code containing the call is within 32MB (26 bits) of
the called routine or (b) the LKM code uses the four-instruction long
call sequence.

Since kernel text is in low memory (it's mapped with VA==PA), this
means putting the LKM there too.  Which, since it's mapped with a BAT
rather than a segment, means finding physically contiguous memory
within 32MB of kernel text (which is currently Hard) or persuading the
code to do long calls (which is where gcc comes into it).  (Or, I
suppose, moving kernel text, which would be
(*cdevsw[major(worm_can->wc_dev)].d_open)(worm_can).)

Personally, I'm inclined to favor the linker hack that was recently
mentioned; it seems to me that it would be useful when someone builds a
program with >32MB of text segment anyway, and would break only when a
single .o file's text, plus any necessary stubs, exceeds 64MB.  It
would also completely sidestep the issue of having to decide which
calls to declare longcall and which shortcall, since the decision would
be made late enough to know which ones actually *need* longcall.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B