Re: RFC: [2.6 patch] disallow modular IPv6

From: Theodore Ts'o (tytso_at_mit.edu)
Date: 09/30/03

  • Next message: Jamie Lokier: "Re: [PATCH] Mutilated form of Andi Kleen's AMD prefetch errata patch" 
    Date:	Tue, 30 Sep 2003 10:21:54 -0400
To: David Woodhouse <dwmw2@infradead.org>

    On Tue, Sep 30, 2003 at 09:26:38AM +0100, David Woodhouse wrote:
    > > The suggestions I see do nothing to enhance the kernel tree as it currently
    > > stands. If you wish to prevent the kernel image from changing due to
    > > out-of-tree modules being built, fine, but don't impose this restriction
    > > upon in-kernel modules.
    >
    > It's a matter of taste. As I said, it's your right to disagree.
    >
    > Some time during 2.7 I'm sure one of the many people who agree with
    > Adrian and myself will send patches to Linus and he'll get to arbitrate.

    FWIW, I agree with Dave. Most of the time, enabling a device driver
    won't cause the core kernel to change, sure.

    However, there will be cases (such as enabling wireless ethernet
    drivers as modules, for example) where in order to support those
    modules, some new core kernel infrastructure will need to be enabled.

    Now, there are a couple of ways ways you can handle this. One is that
    the core infrastructure could have its own CONFIG_infrastructure
    boolean, and if that symbol is 'no', then you won't be able to build
    those modules until you recompile the base kernel with
    CONFIG_infrastructure. Another is that you can make enabling any one
    of the device driver modules "automatically" enable inclusion of the
    base core infrastructure.

    It then all boils down to tradeoffs and aesthetics. By making
    CONFIG_infrastructure explicit, it makes it more clear what is going
    on --- but if it is defaulted on, or if you require that whatever is
    under the CONFIG_infrastructure ifdef is always compiled in, then that
    way leads to kernel boot. But if it is defaulted off, then the user
    will be forced to recompile the kernel anyway, before he/she can
    enable the kernel module in question. Including CONFIG_infrastructure
    explicitly also makes the kernel build process more complex, and can
    also make life more confusing to the user --- the question about
    whether or not you can build a particular device driver won't even
    appear until the user enables CONFIG_infrastructure, and the user may
    have a really hard time figuring out that CONFIG_infrastructure is the
    way to make a particular device driver appear.

    For that reason, I tend to prefer the approach of simply enabling a
    device driver, and then letting that force a change in the base kernel
    to include any necessary base infrastructure in the kernel if
    necessary. It's simpler from a configuration perspective. And if the
    user types "make modules" after making such a change, ideally the
    build system should warn the user that it will be necessary to rebuild
    the base kernel before it can build the module.

                                                    - Ted
    -
    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: Jamie Lokier: "Re: [PATCH] Mutilated form of Andi Kleen's AMD prefetch errata patch"

    Relevant Pages

    • Re: Trap number: how a system software recognise it?
      ... MINIX has no concept of "device recognition". ... discuss how to implement a new device driver - not so much documentation ... > driver code at the kernel space to perform the low level instructions. ... User program issues readlibc function to read some bytes from ...
      (comp.os.linux.misc)
    • Re: Trap number: how a system software recognise it?
      ... MINIX has no concept of "device recognition". ... discuss how to implement a new device driver - not so much documentation ... > driver code at the kernel space to perform the low level instructions. ... User program issues readlibc function to read some bytes from ...
      (comp.os.linux.development.system)
    • Re: Process D-stated in generic_unplug_device
      ... After a recent kernel upgrade (essentially 2.6.15.4 + a selection of other ... Please test vanilla 2.6.16-rc3 and let us know what block device driver is ... element of the production server that I can't duplicate in the lab right now ... Given that we can't replicate the problem on our lab hardware, ...
      (Linux-Kernel)
    • waiting process in procfs read
      ... I submitted this as a bugzilla kernel bug report but was directed here. ... My device driver sets up an entry in the /proc tree. ... If I kill the waiting process I do see "WOKE UP" and "returns error due to ... I can not see any reason why the waiting process wouldn't wake up. ...
      (Linux-Kernel)
    • 11i: Kernel build error - +ES1.Xindirect_calls
      ... We're trying to get a kernel built (with our non-DLKM device driver) on ... an 11i system that's using vPars ... ... Loading the kernel... ... If we put a printf() into our device ...
      (comp.sys.hp.hpux)