Subject: RE: Do LKMs work *at*all* on powerpc platforms?
To: Todd Vierling <tv@wasabisystems.com>
From: Bill Studenmund <wrstuden@zembu.com>
List: port-macppc
Date: 08/07/2000 18:27:06
On Mon, 7 Aug 2000, Todd Vierling wrote:
> On Mon, 7 Aug 2000, Bill Studenmund wrote:
>
> : > > I think adding something like -mlong-call and __attribute__ ((short-call))
> : > > would be the most efficient thing. :-)
Oops! This option would ONLY be for the LKM's, not the kernel compile. :-)
Since the kernel is less than 32 MB big, all its relative jumps are within
the 24-bit relocation's size. Thus it can use the short branches. The
problem is that the way lkm's are loaded, they end up a few GB away from
the rest of the kernel (in KVA, the machine really doesn't have that much
RAM), and so the 24-bit reloc doesn't work.
> (Note that I do have the ppc ref manuals, but I stepped into the thread
> late; I subscribed to port-macppc a week ago.)
Welcome! :-)
> Exactly how much overhead are we looking at between longcall and shortcall
> here? I just want to know how many CPU cycles we're anticipating for the
> difference in calling convention, and whether it could be worth doing
I think 4 instructions as opposed to one.
> -mlong-call universally, or just as a documented prerequisite for
> LKM-capable kernels. You could have something like:
>
> #options LKM # loadable kernel modules
> #makeoptions COPTS="-mlong-call" # required for LKMs to work
We only need this in the lkm's Makefile. The kernel in fact should be
conpiled without it. :-)
Also, could we teach all other ports about it, -mlong-call (and to ignore
it), or make some sort of include file magic happen? It would be nice to
have the optimal thing happen with powerpc lkm's and yet still share
source with other architectures.
Take care,
Bill