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

From: Steve Youngs <sryoungs@bigpond.net.au>
To: Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: PATCH: (as177)  Add class_device_unregister_wait() and platform_device_unregister_wait() to the driver model core
Date: Mon, 26 Jan 2004 15:06:48 +1000	[thread overview]
Message-ID: <microsoft-free.87hdyjs3h3.fsf@eicq.dnsalias.org> (raw)
In-Reply-To: <20040125222242.A24443@mail.kroptech.com> (Adam Kropelin's message of "Sun, 25 Jan 2004 22:22:42 -0500")

[-- Attachment #1: Type: text/plain, Size: 3939 bytes --]

* 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"
  >> >    issue: you reference count a single data structure. It's
  >> >    basically impossible to make a "global" reference count
  >> >    without jumping through hoops.
  >> 
  >> 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 see the process working along these lines: When a module is loaded
  >> into the kernel it (the module) exports a symbol (a function) that the
  >> kernel can use for determining whether or not the module is still in
  >> use.

  > And how will the module know when it is or is not "in use"? By keeping
  > a count of the number of current users, of course.

No, the number of current users wouldn't have any bearing on it whatsoever.
How each module does it would be up to the module itself.  For an ethernet
card it could be while the card is associated with a IP; for a USB keyboard
it could be while the keyboard is plugged in; for a sound driver it could
be while anything is accessing the sound devices. etc etc.

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.

  >> >  - 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.

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

  >> >    Unloading a module happens once in a blue moon, if even then.
  >> 
  >> 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.

Yes, I could be wrong, I sure as anything don't know the full story,
but I'm not convinced that I am wrong yet.

  > Several extremely bright people have tackled the problem and eventually
  > concluded it's extremely hard to solve and generally not worth the
  > trouble. It's time to let go.  

Several extremely bright people thought Galileo was a heretic and a
fool. 

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.

But if you tell me that this problem is too hard to solve, then I have
no alternative than to think: "you're not trying hard enough".

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|              Ashes to ashes, dust to dust.               |
|      The proof of the pudding, is under the crust.       |
|------------------------------<sryoungs@bigpond.net.au>---|

[-- Attachment #2: Type: application/pgp-signature, Size: 256 bytes --]