From: "David S. Miller" <davem@redhat.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: bunk@fs.tum.de, acme@conectiva.com.br, netdev@oss.sgi.com,
pekkas@netcore.fi, lksctp-developers@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: RFC: [2.6 patch] disallow modular IPv6
Date: Tue, 30 Sep 2003 01:08:55 -0700 [thread overview]
Message-ID: <20030930010855.095c2c35.davem@redhat.com> (raw)
In-Reply-To: <1064907572.21551.31.camel@hades.cambridge.redhat.com>
On Tue, 30 Sep 2003 08:39:33 +0100
David Woodhouse <dwmw2@infradead.org> wrote:
> And you don't see why it's confusing that turning something on as a
> _module_ changes the contents of the kernel image?
For something in the kernel tree, no I don't.
> 99% or more of tristate options can be enabled without affecting the
> kernel, and it is expected that such options can be set to 'm' later,
> while the kernel in question is actually running, then built and loaded
> without a reboot.
Expected by whom? Not by me.
> We should strive to keep this true.
For things _OUTSIDE_ the kernel, surely. But inside the kernel
tree I don't see any value in this new restriction.
> Allow this kernel to ever support IPv6? Y/N
> Build IPv6 support? Y/M/N
And I still think this is a complete joke.
If the user sets CONFIG_IPV6 to 'm' from 'n', and make then creates a
new kernel image for him (which it will if dependencies are working
correctly), if he can't figure out that he's gotta install that thing
maybe he should enable module symbol versions to protect him from
insmod'ing that ipv6 module by mistake.
Actually, he won't be able to anyways since only the new kernel exports
a bunch of ipv4 symbols which ipv6 needs.
We could even somehow 'tag' the ipv4 core such that the ipv6 module
can check whether it knows that ipv6 was built as a module or not.
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.
next prev parent reply other threads:[~2003-09-30 8:08 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-28 22:59 RFC: [2.6 patch] disallow modular IPv6 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 [this message]
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
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=20030930010855.095c2c35.davem@redhat.com \
--to=davem@redhat.com \
--cc=acme@conectiva.com.br \
--cc=bunk@fs.tum.de \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lksctp-developers@lists.sourceforge.net \
--cc=netdev@oss.sgi.com \
--cc=pekkas@netcore.fi \
/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;
as well as URLs for NNTP newsgroup(s).