All exception handling on the PowerPC starts off with translation disabled,
hence the convenience of having the 1:1 mapping.  There's no valid way to
enable translation without at least some 1:1 mapped code, or at least that's
my understanding of the programming environment.

Also, the 1:1 mapping uses a BAT register, which requires no memory accesses
for address translation, which makes it faster than using PTEs to map the
kernel.  The kernel is, after all, aware of the architecture of the machine
so it is not a "hack" to take advantage of such a performance improvement.

I believe the solution is to do something like the following:

#ifdef COMPILING_AN_LKM
#ifdef powerpc
#ifdef __GNUC__
#define LKMATTR   __attribute__ ((far))
#else
#error don't know how to force far calls
#endif /* __GNUC__ */
#endif /* powerpc */
#else
#define LKMATTR   
#endif

int LKMATTR memcpy __P(...);

Obviously I'm making up the names and stuff, this is just the idea that
needs to be followed.  When compiling an LKM, you'd have to specify
-DCOMPILING_AN_LKM to the compiler, or equivalent.  When doing the kernel
proper, don't specify that.

As mentioned by others, calls from the kernel to a LKM are handled by
pointers already.

Oh, and to answer the suggestion of just using far calls for everything, a
far call is 4 instructions  (lis rA,addr@ha; addi rA,addr@l; mtctr rA;
bctr), a short call is 1 instruction (b addr).  That works out to roughly 4x
performance on the short call.  So don't be using far calls for everything.
(Oh, if you have to preserve the CTR register, add two instructions for that
to the far call, too).

While you're at it, try not to start any religious wars, either... :-)

Gregory

> -----Original Message-----
> From: ws@tools.de [mailto:ws@tools.de]
> Sent: Wednesday, August 02, 2000 2:49 PM
> To: dgatwood@deepspace.mklinux.org
> Cc: port-macppc@netbsd.org
> Subject: Re: Do LKMs work *at*all* on powerpc platforms?
> 
> 
> > If it's laid out that way, then that's a hack, and therein 
> lies the real
> > problem.  :-)
> 
> It's not more of a hack than any other design decision.  
> Remember that not
> all of the world is Linux.
> 
> > A much better answer is to deal with it that way only for
> > initial bootstrap (until VM is up), then set aside a whole 
> PTEG for kernel
> > space (say, PTEG 0), but map exactly what is needed for the 
> kernel.  Then
> > when you load a module, add another PTE into group 0.
> 
> Huh?  AFAICT, a PTEG contains just 8 mappings, so you can map at most
> 32 KB with one PTEG.  Not too much :-).
> 
> > The Mach VM
> > implementation under MkLinux does something along these 
> lines, as far as I
> > can tell from trivial perusal.  And we all know how big its 
> "modules" 
> > (servers) can be.  :-)
> 
> I don't have a clue.  And I don't give a damn either.
> 
> > Yes, but you wouldn't _want_ all functions to be compiled 
> that way -- just
> > the ones that cross module/kernel boundaries.  It really 
> should be done on
> > a function by function basis if you elect to use this 
> method, but fixing
> > the kernel mapping is probably easier, and much more flexible.  :-)
> 
> Why not?  1. it will be done only for LKMs, and 2. it's more or less
> done this way for the PowerOpen ABI on all function calls, so 
> it probably
> isn't too bad.
> 
> Ciao,
> Wolfgang
> -- 
> ws@TooLs.DE     Wolfgang Solfrank, TooLs GmbH 	+49-228-985800
>