Philipp Rumpf wrote:
>
> On Fri, Oct 27, 2000 at 10:49:53PM +1100, Andrew Morton wrote:
> > Look, this modules stuff is really bad. Phillip Rumpf proposed
> > a radical alternative a while back which I felt was not given
>
> While it might be a "radical alternative", it doesn't require any changes
> to the subsystems that have been fixed so far. At this time, applying the
> patch would basically fix the rest of the subsystems as well (if the
> drivers use MOD_{INC,DEC}_USE_COUNT, that is).
>
> > sufficient consideration. The idea was to make sys_delete_module()
> > grab all the other CPUs and leave them spinning on a flag while
> > the unload was proceeding. This was very similar to
> > arch/i386/kernel/apm.c:apm_power_off().
>
> The idea here is other CPUs don't have to deal with the kernel going
> through a number of inconsistent states while a module is unloaded. At
> any point in time, for any module, exactly one of the following is true:
>
> 1. you're in the module_exit function
> 2. the module is (being) loaded
> 3. the module isn't loaded.
>
> > As far as I can recall, the only restriction was that you are
> > not allowed to call module functions when the module refcount
> > is zero if those functions can call schedule().
>
> There are other restrictions which shouldn't really matter:
>
> - you can't schedule() and hope you end up on a particular CPU (you can
> use smp_call_function though)
>
> - you can't copy_(from|to)_user in the module exit function (which would
> be copies from/to rmmod anyway)
Unfortunately, you need to be able to use copy_*_user() from the network
ioctls, and this is the center of the current issue.
--
Brian Gerst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
