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/