Messages in this thread | | | Date | Wed, 11 Sep 2002 11:28:52 -0400 (EDT) | From | Bill Davidsen <> | Subject | Re: Question about pseudo filesystems |
| |
On Mon, 9 Sep 2002, Daniel Phillips wrote:
> > The expected behaviour is as it has always been: rmmod fails if anyone > > is using the module, and succeeds if nobody is using the module. The > > garbage collection of modules is done using "rmmod -a" periodically, as > > it always has been.
I can't disagree with any of that, but the idea of releasing resources when they are not in use and preventing new use of the resource from the time of the release request is hardly new to UNIX. It's exactly the way filespace is treated when a file is unlinked while open.
> Al's analysis is all focussed on the filesystem case, where you can > prove assertions about whether the subsystem defined by the module is > active or not. This doesn't cover the whole range of module applications.
Which if true doesn't preclude solving the problems it does address.
> There is a significant class of module types that must rely on sheduling > techniques to prove inactivity. My suggestion covers both, Al has his > blinders on.
Clearly there are people who don't agree, and you don't help by insulting them. I'd like a single solution, but it looks as if Al's idea will work for filesystems, and it's relatively simple.
> Designs are not always correct just because they work.
Solutions which work are most certainly correct, and no degree of elegance will make a non-working solution correct for any definition of correct I use. I think you mean "optimal" here, and clearly an optimal solution is simple, reliable, efficient, general, and easy to code and understand. Anything less is subject to improvement, and that certainly applies to module removal ;-)
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
- 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/
| |