Re: [PATCH][RFC] new module interface

[Roman Zippel]

Hi,

On Thu, 25 Jul 2002, Rusty Russell wrote:

> 	Firstly, I give up: what kernel is this patch against?  It's
> hard to read a patch this big which doesn't apply to any kernel I can find 8(

2.4.18. Maybe pine garbled the patch... Here is a copy of the patch:
http://www.xs4all.nl/~zippel/mod.diff

> Interesting approach.  Splitting init and start and stop and exit is
> normal, but encapsulating the usecount is different.  I made start
> and exit return void, though.

I introduced usecount() to gain more flexibility, currently one is forced
to pass the module pointer everywhere.
Allowing exit to fail simplifies the interface. Normal code doesn't has
to bother about the current state of the module, instead exit() is now the
synchronization point. This also means the unload_lock via
try_inc_mod_count is not needed anymore.

> Hmmm... you sidestepped the "rmmod -f" problem, by running module->start()
> again if module->exit() fails.  I decided against this because module
> authors have to make sure this works.

In the future it rather should work. The problem is that the current
module interface is very limited, later we can introduce a interface to
just stop a module. Right now I just emulate the old behaviour to avoid
having a module in half initailized state.

> I chose the more standard "INIT(init, start)" & "EXIT(stop, exit)" which
> makes it easier to drop the exit part if it's built-in.

I was thinking about it, but couldn't we just put these function in a
seperate section and discard them during init (maybe depending on some
hotplug switch)?

> My favorite part is including the builtin-modules.  I assume this means
> that "request_module("foo")" returns success if CONFIG_DRIVER_FOO=y now?

Not yet. The problem is the module name, e.g. ext2 is called
fs_ext2_super, it will need some kbuild changes to get the right module
name.

bye, Roman