lkml.org 
[lkml]   [2002]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Rusty's module talk at the Kernel Summit


    On Wed, 10 Jul 2002, David S. Miller wrote:

    > From: Rusty Russell <rusty@rustcorp.com.au>
    > Date: Thu, 11 Jul 2002 12:48:30 +1000
    >
    > For God's sake, WHY? Look at what you're doing to your TLB (and if you
    > made IPv4 a removable module, I'll bet real money you have a bug unless
    > you are *very* *very* clever).
    >
    > Modules can be mapped using a large PTE mapping.
    > I've been meaning to do this on sparc64 for a long
    > time.
    >
    > So this TLB argument alone is not sufficient :-)
    > I do concur on the "ipv4 as module is difficult to
    > get correct" argument however.

    Sure, but consider the amount of tricky modules and amount of easy ones.
    net/ipv4/*.c _is_ tricky; so much that having system with many parts of
    such complexity would be extremely painful.

    IOW, yes, we have some very tricky interfaces between the parts of kernel;
    and their trickiness alone guarantees that we don't want to have them
    breeding. Stuff that genuinely needs complex interfaces is *not* something
    you want to be mass-produced.

    Do we need to disable rmmod when
    a) 90-odd percents of modules can be handled safely and
    b) any module that wants to prevent rmmod on itself can do that
    with one line in its init_module() (add MOD_INC_USE_COUNT; and that's it)?

    Notice that generic netfilter module and, say it, driver that provides
    a character device are very different beasts. The latter can be easily
    handled in safe way; it has simple use model and very few places in
    core code that need to take care of the things - at once for all such
    modules. The former is much trickier. The thing being, there are
    hundreds of simple modules and a dozen or so tricky ones. And as the
    time goes the ratio will only increase, presuming that we want some
    sanity for the tree. With complex interfaces .text is not the only
    thing that needs nontrivial protection, to put it mildly.

    I'd rather get the simple (== large) classes into decent shape and then
    deal with what's left. FVO "deal" possibly including "no rmmod for these
    guys".

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

    \
     
     \ /
      Last update: 2005-03-22 13:27    [W:3.200 / U:0.228 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site