On Fri, Dec 19, 2008 at 08:56:14AM +0000, Richard Earnshaw wrote:
> On Fri, 2008-12-19 at 01:44 -0500, Rafal Boni wrote:
> > On Thu, Dec 18, 2008 at 09:35:02PM -0800, Matt Thomas wrote:
> > > Yes. PC24 is not appropriate in dynamic shared library loading but
> > > since kernel modules are simple .o files, it is appropriate.
> >
> > Ok, so the next hole I fall into is symbols being too far for the PC24
> > reloc to resolve (printf in the example modules), and a crash related
> > to the auto-loading of the compat module.
> >
> > The second one I haven't dug into very much (it gave me a reason to give
> > up for the night), but the first is interesting -- in the old LKM frame-
> > work, the lkmtramp.awk scripts generated trampoline code for all targets
> > of PC24 relocs... do we have an equivalent for the new modules? Where is
> > this supposed to happen in the new world order?
> >
> > Thanks,
> > --rafal
> >
>
> It might be appropriate to compile kernel modules with -mlong-calls.
> That way all the relocations to functions are turned into DATA relocs.
> Doing that will simplify cache synchronization issues as well.
module_map is there to solve this problem without PIC overhead or slower
addressing modes. Here are two possible approaches:
- In MD code reserve a region of VA space close to the kernel text/data and
set up module_map to cover it. What's needed is a region in kernel space
that will not be used for anything else. No memory need be allocated to
it. amd64 works this way:
http://nxr.homeunix.org/source/xref/sys/arch/amd64/amd64/machdep.c#354
- If the region covered by kernel_map is close enough to the text/data, you
could allocate a submap from it during early boot. See uvm_km_suballoc().
Thanks,
Andrew