In message <Pine.LNX.4.44.0207251121310.28515-100000@serv> you write:
> 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
Much better: thanks!
> > 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.
Well, you substituted the module pointer for an atomic counter. Bit
of a wash, really.
> 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.
Except that rmmod fails rather frequently on busy modules. Which
might be ok.
> > 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)?
No, if you drop them newer binutils notices the link problem, hence
the __devexit_p(x) macro.
> > 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.
I need that too: the mythical "KBUILD_MODNAME". Both Keith and Kai
promised it to me...
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/
This archive was generated by hypermail 2b29 : Tue Jul 30 2002 - 14:00:22 EST