Re: ARM kernel module supported reloc types

[Andrew Doran <ad%netbsd.org@localhost>]

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