Re: Userspace Test Framework for module loader porting

[Rusty Russell <rusty@rustcorp.com.au>]

In message <Pine.GSO.3.96.1030113114240.25230B-100000@delta.ds2.pg.gda.pl> you 
write:
> On Mon, 13 Jan 2003, Rusty Russell wrote:
> 
> > > I'm also a bit worried about changing module loaders so often.  Yeah,
> > > once you switch to a kernel-loader, presumably users won't be
> > > affected, but (kernel-module) developers will be.
> 
> Hmm, what's the gain from using shared objects as opposed to relocatables
> and why is there any for non-PIC objects at all?

[ Other maintainers dropped from CC, they're probably not that interested ].

Basically it comes down to ET_DYNs being designed to be easy to load.
For most archs, new sections don't have to be allocated (eg. plt,
GOT).  Sections don't have to be sorted, or layed out.  As you point
out, relocations are bundled nicely together, etc.

On some architectures, making the linker do more of the work makes a
significant difference (eg. in ia64 it generates the stub code to jump
out of modules).  The module being layed out continuously, however,
means we need a "vmalloc_truncate" to free init sections (except for
archs which use their own alloc functions anyway).

Like most things, it's a tradeoff.  19 archs makes it even more complex.
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.