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

Rusty Russell (rusty@rustcorp.com.au)
Fri, 20 Sep 2002 09:44:23 +1000


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.
-
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/