[lkml]   [2004]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: PATCH: (as177) Add class_device_unregister_wait() and platform_device_unregister_wait() to the driver model core
    On Sun, Jan 25, 2004 at 11:02:58AM -0800, Linus Torvalds wrote:
    > The proper thing to do (and what we _have_ done) is to say "unloading of
    > modules is not supported". It's a debugging feature, and you literally
    > shouldn't do it unless you are actively developing that module.
    > Sadly, some modules are broken. Old 16-bit PCMCIA in particular _depends_
    > on unloading modules, since the old PCMCIA layer doesn't do hotplug: it
    > literally thinks of module load/unload as the "plug/unplug" event.
    > 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.
    > (As an example of "too painful, too slow", think of something like a
    > packet filter module. You'd literally have to increment the count in every
    > part that gets a packet, and decrement the count at every point where it
    > lets the packet go. And since it would have to be SMP-safe, it would have
    > to be a locked cycle, or we'd have to have per-CPU counters - at which
    > point you now also have to worry about things like preemption and
    > sleeping, which just means that it would be a _lot_ of very fragile code).

    Packet filter is hardly a normal module. For absolute majority of modules
    it's nowhere near that bad.

    HOWEVER, module unload is not the real problem. We have objects with
    limited lifetimes. Always had, always will. Whether we remove pieces
    of .text from the in-core kernel or not, we must be able to deal with
    that. Even if methods themselves are present, they won't do you any
    good when data structures belonging to object are destroyed.

    If that is handled right, rmmod is trivial for 99% of modules. The
    rest (including Rusty's stuff) can simply say "we can't be unloaded
    at all" and be done with that.

    Basically, "protect the module" is wrong - it should be "protect specific
    object" and we need that anyway. We already have that for the largest
    class of modules - 300-odd netdev ones. We have that for filesystems.
    We have that for block devices. We have infrastructure for doing that
    to character devices, ttys and ldiscs. Which leaves us with truly weird
    stuff that doesn't work in such terms and yes, there your arguments

    Frankly, I'm much more concerned about the stuff that _can't_ be disabled.
    You can disable module unloading; hell, you can disable modules completely.
    You can't disable ifdown(8). Which currently means very bad things for
    stuff in /proc/sys/net/ipv4/{conf,neigh}/*. And all arguments re rmmod
    deadlocks apply to that sort of situations...
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:00    [W:0.022 / U:78.216 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site