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

[Steve Youngs <sryoungs@bigpond.net.au>]

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

* 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?  For example:

  - The cdrom module is "in use" when a cdrom filesystem is mounted
    and it isn't "in use" when there are _no_ cdrom filesystems
    mounted. 

  - An ethernet module is "in use" while the device is attached to an
    IP. 

  - A packet filter module is "in use" while there are iptables rules
    (or similar) existing that require 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.  If no such symbol is exported the kernel would mark the module
as being "non-unloadable" (its refcount would always be non-nil), and
send an appropriate message to root via syslog saying "xyz module
cannot be automatically unloaded".

It should also be possible for modules to tell the kernel, through the
same mechanism, that they should _never_ be unloaded.

I don't, yet, have the knowledge to turn my ideas into code so I won't
be offended in the slightest if you ignore them.  Just tell me
why. :-) 

  >  - lack of testing. 

A moot point once the kernel can safely and efficiently do module
unloading. 

  >    Unloading a module happens once in a blue moon, if even then.

We get an awful lot of blue moons here.

  > The proper thing to do (and what we _have_ done) is to say
  > "unloading of modules is not supported".

Wouldn't it be better to say "unloading of modules is currently
discouraged because we haven't _yet_ solved the problems related to
unloading modules".

  > But it basically boils down to: don't think of module unload as a "normal
  > event". It isn't. Getting it truly right is (a) too painful and (b) would
  > be too slow, so we're not even going to try.

Now there's a cop out if ever I saw one.  Surely, Linus, you've
overcome _much_ bigger problems than this at different times.  Just
because the only solutions that have been thought of so far are hard
to implement, are too inefficient, and aren't very safe doesn't mean
you should give up.  It just means that you need a different
solution. 

  > (As an example of "too painful, too slow", think of something like a 
  > packet filter module.

See my examples above.



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