lkml.org 
[lkml]   [2002]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] In-kernel module loader 1/7
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
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:29    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site