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

From: Steve Youngs (sryoungs_at_bigpond.net.au)
Date: 01/26/04

  • Next message: Eric: "Re: 2.6.2-rc1-mm2 kernel oops"
    To: Linux Kernel List <linux-kernel@vger.kernel.org>
    Date:	Mon, 26 Jan 2004 09:12:58 +1000
    
    

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

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



  • Next message: Eric: "Re: 2.6.2-rc1-mm2 kernel oops"

    Relevant Pages

    • Re: bugs in kernel 2.6.21 (both two release candidates) and kernel 2.6.20
      ... Von: Linus Torvalds ... Betreff: Re: bugs in kernel 2.6.21 and kernel 2.6.20 ... long lines, proper paragraphs, and it means whitespace in between ... But please do not compare me with maintainers, especially never in this life with the suboptimal one from linuxtv.org being in question. ...
      (Linux-Kernel)
    • Driver crashes after unloading a module
      ... We have written driver for hdlc controller .The kernel is crashing ... after unloading ... resources while detaching the device. ... static int hdlc_detach ...
      (freebsd-hackers)
    • Re: Why no /proc/config.gz on FC-3 kernel?
      ... >> as decided presumably by Linus Torvalds, ... I don't see the point of Fedora doing things differently. ... I did in fact google, IIRC, for "fedora kernel config" ...
      (Fedora)
    • Re: [OT]: Maybe SCO is (partially) right
      ... I would find it hard to believe that Linus Torvalds ... > a first-pass kernel, sans the userland tools that folks are used to ... > functionality, and scope of VMS. ...
      (comp.os.vms)
    • Re: Kernel numbers
      ... 1.741_FC3 is the Fedora version of the kernel. ... Linus Torvalds produces "base" kernels every few months. ... Fedora version of the kernel, which gets its own numbering system based ... James Wilkinson ...
      (Fedora)