Alexander Viro writes:
>
>
> 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.
>
> > - 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)
>
> - let the caller do refcounting (one place in code vs. several dozens and
> that - for each subsystem)
>
> - make sure that caller uses try_inc_mod_count() (automatically takes care
> of all issues with cleanup_module() blocking).
>
> And you are telling that the former is less brittle? <boggle>...
Think for a moment. The scheme that I proposed (a variant of the
scheme Rusty, Philip et. al. proposed) will work reliably without
kernel hacks. The scheme you propose is naturally brittle, because it
requires a pile of structural changes to the kernel, bloating a
variety of structures, and *still* isn't entirely safe (someone could
foul up somewhere).
Blocking other CPUs is also conceptually simpler. With your scheme
it's harder to follow what's happening (because they're hidden behind
some other layer).
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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:05 EST