mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dana Lacoste <dana.lacoste@peregrine.com>
To: "David S. Miller" <davem@redhat.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
	netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: RFC: [2.6 patch] disallow modular IPv6
Date: Tue, 30 Sep 2003 09:44:55 -0400	[thread overview]
Message-ID: <1064929494.98525.7.camel@dlacoste.ottawa.loran.com> (raw)
In-Reply-To: <20030930022410.08c5649c.davem@redhat.com>

On Tue, 2003-09-30 at 05:24, David S. Miller wrote:
> What this means is that it's required for the kernel image to be up to
> date before any modules can be built.  If we can check that in the
> build system for the sake of modversions (and if we're not doing that
> now it's a bug we should fix) we can do it equally for ipv6.

So this procedure is flawed then :

1. Compile kernel.  Set up everything that you need,
   IPV6 is set to 'n'
2. Install kernel and modules to your liking, reboot to take effect.

5 minutes later a user comes and complains that IPV6 isn't available
and he will want it later, so you decide to compile the module for
when he needs it and avoid another reboot :

3. Change config IPV6 to 'm'
4. run make modules && make modules_install

I think that arguing that the kernel image is out of date
is preposterous in this case.  It was built just before the
config was changed!

I'm not saying that changing the kernel is an invalid, I'm only
saying that documentation should be updated to mention explicitly :

If you are adding a kernel module to your config, you must also
recompile your kernel and use the new kernel before you use that
module.  Essentially, modules are useful only for hotplugging type
situations and not for ease of developer access to kernel drivers.

I agree with Mr. Woodhouse in that this is completely non-intuitive
and is absolutely not what most linux users think of as expected
behaviour, but I can understand how something like IPV6 changes too
many things to be reliably build as a module in this fashion.

SO

TO GET TO MY POINT :)

Why can't the subject line of this thread be implemented?  If IPV6
isn't modular, then WHY ALLOW IT AS A MODULE?

Dana Lacoste
Ottawa, Canada


  parent reply	other threads:[~2003-09-30 13:44 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-28 22:59 Adrian Bunk
2003-09-28 23:18 ` Arnaldo Carvalho de Melo
2003-09-28 23:24   ` Adrian Bunk
2003-09-28 23:39     ` Arnaldo Carvalho de Melo
2003-09-28 23:47       ` Arnaldo Carvalho de Melo
2003-09-29  0:14       ` Adrian Bunk
2003-09-29  0:32         ` Arnaldo Carvalho de Melo
2003-09-29  9:02           ` David Woodhouse
2003-09-29 14:15             ` Arnaldo Carvalho de Melo
2003-09-29 14:28               ` Jan Evert van Grootheest
2003-09-29 14:29               ` David Woodhouse
2003-09-29 14:38               ` Valdis.Kletnieks
2003-09-29 14:46                 ` David Woodhouse
2003-09-30  5:17             ` David S. Miller
2003-09-30  6:31               ` David Woodhouse
2003-10-01 19:47                 ` Guennadi Liakhovetski
2003-09-30  5:11           ` David S. Miller
2003-09-30 13:37             ` Adrian Bunk
2003-09-30 15:04               ` Arnaldo Carvalho de Melo
2003-10-01  6:39                 ` David S. Miller
2003-09-30  5:09     ` David S. Miller
2003-09-30  6:32       ` David Woodhouse
2003-09-30  7:03         ` David S. Miller
2003-09-30  7:39           ` David Woodhouse
2003-09-30  8:08             ` David S. Miller
2003-09-30  8:26               ` David Woodhouse
2003-09-30  8:30                 ` David S. Miller
2003-09-30  8:42                   ` David Woodhouse
2003-09-30  8:51                     ` David S. Miller
2003-09-30  9:14                       ` David Woodhouse
2003-09-30  9:17                         ` David Woodhouse
2003-09-30  9:24                         ` David S. Miller
2003-09-30  9:57                           ` Sam Ravnborg
2003-09-30 10:02                           ` David Woodhouse
2003-09-30 10:01                             ` David S. Miller
2003-09-30 10:14                               ` David Woodhouse
2003-09-30 11:39                             ` Sam Ravnborg
2003-09-30 13:44                           ` Dana Lacoste [this message]
2003-09-30 13:50                           ` Kai Germaschewski
2003-09-30 15:13                   ` Richard Guy Briggs
2003-09-30 14:21                 ` Theodore Ts'o
2003-09-30 14:51                   ` David Woodhouse
2003-09-30 12:06               ` Olivier Galibert
2003-09-29  6:29 ` Pekka Savola

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1064929494.98525.7.camel@dlacoste.ottawa.loran.com \
    --to=dana.lacoste@peregrine.com \
    --cc=davem@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lksctp-developers@lists.sourceforge.net \
    --cc=netdev@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®