Re: [PATCH] In-kernel module loader 1/7

[Daniel Jacobowitz <dan@debian.org>]

On Thu, Sep 19, 2002 at 11:00:23AM +1000, Rusty Russell wrote:
> In message <Pine.LNX.4.44.0209182313360.8911-100000@serv> you write:
> > Hi,
> > 
> > On Wed, 18 Sep 2002, Rusty Russell wrote:
> > 
> > > 	I've rewritten my in-kernel module loader: this version breaks
> > > much less existing code.  Basically, we go to a model of
> > > externally-controlled module refcounts with possibility of failure
> > > (ie. try_inc_mod_count, now called try_module_get()).
> > 
> > You add a lot of complexity in an attempt to solve a quite simple problem.
> > I agree that the module load mechanism could be simplified, but why do you
> > want to do it in the kernel?
> 
> Count the total lines of code in the kernel.  It's less than it was
> before.  Even for ia64, it's around the same IIRC.
> 
> Now add the userspace code, and it's obviously far simpler.  Not to
> mention not having to worry about problems like insmod dying between
> the two system calls...
> 
> I'm all for keeping things out of the kernel, but you can take things
> too far.  I was originally reluctant, but the beauty and simplicity of
> doing it in-kernel changed my mind.

I still think that the kernel has no business knowing how to parse ELF
relocation.  It's just as easy to parse it in userspace; and what do
you gain from moving the complexity from userspace to kernelspace?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer