In message <200006242344.RAA02891@puffin.external.hp.com> you write:
> On Sat, 24 Jun 2000, Richard Gooch wrote:
>
> > Yeah, forget that. It won't work. But what should work is if rmmod does:
> >
> > - if refcount != 0, fail
> >
> > - launch N-1 RT threads which just hog their CPUs
> >
> > - wait for RT threads to start (use a pipe, say)
> >
> > - if refcount != 0, kill RT threads and fail
> >
> > - remove module
>
> - pray that cleanup_module() does not block in bad moment.
cleanup_module can block whenever. I don't understand what you're
trying to say here?
> > - kill RT threads and exit with success.
>
> ... compared to
>
> - kill MOD_INC_USE_COUNT/MOD_DEC_USE_COUNT (along with quite a few
> ->open()/->release(), BTW)
Adding a field to every registerable structure is gross. The
responsibility for getting modules right should be with the person
writing the modules. The rules are simple; and people w/o module
support don't pay the penalty for the extra field everywhere...
> - make sure that caller uses try_inc_mod_count() (automatically takes care
> of all issues with cleanup_module() blocking).
This function is non-intuitive, adds code complexity, changes
well-established rules, and is completely undocumented.
The proposed solution keeps old semantics. Not only is that much
preferable this stage of development, it's *always* preferable to
avoid gratuitous change!
The following two rules should be sufficient:
1) Don't increase module count in softirq/bh/hardirq
2) Don't sleep before increasing module count, or after decreasing
module count.
You can sleep all you want in cleanup() and init().
Orthogonal to this, the current module.c code needs a rewrite; it is
(understatement) unneccessarily complex.
Enjoy!
Rusty.
-- Hacking time.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jun 26 2000 - 21:00:06 EST