[lkml]   [2002]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:29    [W:0.021 / U:85.664 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site