PS, none of this has yet fixed the problem I detail in
http://mail-index.netbsd.org/port-macppc/2000/08/13/0013.html.
Basically, even if you do __attribute__ ((longcall)) on all the
functions you call outside of the LKM, you STILL get loading errors
with a few things (memcpy() showed up for me) because gcc loads them
as builtins. A -mlong-calls flag on gcc "should" get this right
(according to Todd Vierling), though I'm unsure whether I believe
that, because...

Defining the memcpy() prototype with the longcall attribute
setting to be extern in the variable declaration section of the
function block using memcpy() (note that this bloats my code
exponentially more than being able to just redefine that prototype
once for my entire file, and yes, it really does need to be done
local to the calling function because of some gcc semantic I do not
recall right now) causes the module to build properly but not to
actually link into the kernel. For details on this, see (please
disregard the business about UVM, as I think it's to everyone's
benefit to keep the two things separate, and wish I'd seen that at
the time):
http://mail-index.netbsd.org/port-macppc/2000/08/19/0000.html
http://mail-index.netbsd.org/port-macppc/2000/08/21/0004.html

One thing I have not tried, suggested inadvertently by Todd in
http://mail-index.netbsd.org/port-macppc/2000/08/21/0005.html is to
compile the LKM with -mdata=eabi. Perhaps that would make the module
link with the kernel correctly (though using .sdata2 for far calls
shouldn't be necessary since that's a different mechanism for doing
what I'm trying to do with __attribute__ ((longcall)) instead,
right?), but our gcc doesn't even know what to do with -mdata=eabi
anyway:

cc -D_LKM -D_KERNEL -I/sys -mdata=eabi  -c miscmod.c
cc1: Invalid option `data=eabi'
*** Error code 1

Stop.

Since eabi is rather powerpc-specific, oughtn't this really work on
a powerpc? Todd? Anybody?

       ~ g r @ eclipsed.net