Re: PATCH: (as177) Add class_device_unregister_wait() and platform_device_unregister_wait() to the driver model core

[Adam Kropelin <akropel1@rochester.rr.com>]

On Mon, Jan 26, 2004 at 03:06:48PM +1000, Steve Youngs wrote:
> * Adam Kropelin <akropel1@rochester.rr.com> writes:
> 
>   > On Mon, Jan 26, 2004 at 09:12:58AM +1000, Steve Youngs wrote:
>   >> * Linus Torvalds <torvalds@osdl.org> writes:
>   >> 
>   >> >  - doing proper refcounting of modules is _really_ really
>   >> >    hard. The reason is that proper refcounting is a "local"
>   >> 
>   >> Please understand that I coming from an _extremely_ naive perspective,
>   >> but why do refcounting at all?  Couldn't the refcount be a simple
>   >> boolean?
> 
>   > A boolean is just a one-bit reference count. If the maximum number of
>   > simultaneous 'users' for a given module is one, then a boolean will work.
>   > If there is potential for more than one simultaneous user then you need
>   > more bits.
> 
> Why?  A module is either being used or it isn't, the number of uses
> shouldn't even come into it.

I think others in the thread have adequately explained the details
you're missing.

> I'm suggesting that the responsibility for determining when it is safe
> to unload a particular module should lay with the module itself and
> not with the kernel.

That does not change anything at all. The same problems apply and the
same pool of solutions is still available. The easy cases are still easy
and the hard cases are still *really* hard.

>   >> >  - lack of testing. 
>   >> 
>   >> A moot point once the kernel can safely and efficiently do module
>   >> unloading. 
> 
>   > I don't follow your logic. Once it works we don't have to test it so 
>   > therefore we never need to test it?
> 
> Possibly a poor choice of words on my part.  What I meant was that
> once the functionality goes into the kernel testing will happen on
> every single Linux box in the land that has this future kernel.  Some
> of those users will report bugs if there are any.  And some of those
> users may even help to fix those bugs.

Hello? 2.4, etc. support removing modules. Linus was speaking from
experience. One of the reasons module removal is perpetually broken in
subtle ways on those kernels is that it simply does not receive enough
testing. Having some new implementation on 2.6 doesn't change that.

> Also what I meant is that you can't test something that doesn't
> exist.

As I pointed out above, it does exist.

>   >> We get an awful lot of blue moons here.
> 
>   > This moon's not worth barking at.
> 
> There are an awful lot of users out there who would disagree with you
> on that.  _One_ of the reasons that I believe that this moon is worth
> barking at is:
> 
> If a module should never, in the normal course of events, be unloaded,
> then there isn't _any_ point to being able to load them in the first
> place.  Not being able to unload them _totally_ defeats the purpose of
> modules.

Think a little harder and you'll see why that's a ridiculous conclusion.
Hint #1: Distributions. Hint #2: SILO.

> Tell me that this problem is _impossible_ to solve and providing you
> can show me _why_ it is impossible I'll speak no more on this
> matter.

No one yet has claimed this is "impossible" to solve, only that it's not
worth solving. Clearly it's important to you, so have at it. Further
discussion of how you "see the answer so clearly" and the rest of us are
"not trying hard enough" should come in the form of patches.

--Adam