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

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

In message <Pine.LNX.4.44.0209191532110.8911-100000@serv> you write:
> Hi,
> 
> On Thu, 19 Sep 2002, Rusty Russell wrote:
> 
> > If every single object in the kernel is reference counted, *yes* you
> > can do this.  But they're not, and they will never be.  Changing them
> > over to use try_module_get() is feasible, though.
> 
> Rusty, slowly I'm pissed. :(

Sorry if I haven't been as clear as I might wish.  I shall try: I do
appreciate your patience.

1) You keep ignoring the load race problem.  Your solution does not
   solve that, so you will need something else as well.

2) Several places in the kernel do *not* keep reference counts, for
   example net/core/dev.c's dev_add_pack and dev_remove_pack.  You
   want to add reference counts to all of them, but the only reason
   for the reference counts is for module unload: you are penalizing
   everyone just *in case* one is a module.

3) The cost of doing atomic_incs and decs on eg. our network performance
   is simply unacceptable.  The only way to avoid hitting the same
   cacheline all the time is to use bigrefs, and the kernel bloat will
   kill us (and they're still not free for the 99% of people who don't
   have IPv4 and TCP as modules).

4) Your solution does not allow implementation of "rmmod -f" which
   prevents module count from increasing, and removes it when it is
   done.  This is very nice when your usage count is controlled by an
   external source (eg. your network).

Now, your proposal *can* be modified to address these things, but I'm
not sure you'll like your proposale when that's done 8(

Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.