Few facts :
1) You can't get away without refcounting the module users,
unless you implement weak pointers in the kernel
2) You can do refcounting in the module itself (old way, 2.2, 2.4)
3) You can do refcounting in the module users (new way)
4) The module code itself can't do the refcounting, unless it puts
itself explicitely between the module and its users and
understand the usage semantic of the module APIs
> >To be honest, I'd rather just disallow module unloading or
> >let them stay buggy than put this hack into the tree.
> >Special hacks are for 2.4.x where things like full cleanups are not allowed.
>
> It's not a special hack. If it has problems let's fix them.
Well, there is still some time before 2.6.X, but not that
much. We understand what the issues are, we now some of the solutions,
now we just need a schedule and implement those. I personally don't
care too much of the details as long s there is a solution.
When are we supposed to get a preview of the "right" way to do
it ?
> I want to keep Bluetooth socket modules loadable and unloadable. And
> I'm sure Jean and other folks want's the same thing for IrDA and
> other subsystems with sockets.
IrDA sockets will be unloadable, because IrDA wants to be
modular, and people need to unload it to do CIR. So, for me the issue
is more the probability of crashing the system.
> Thanks
> Max
Have fun...
Jean
-
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/