Re: Userspace Test Framework for module loader porting

From: Rusty Russell (rusty@rustcorp.com.au)
Date: Mon Jan 13 2003 - 19:01:15 EST


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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed Jan 15 2003 - 22:00:48 EST