mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Arnaldo Carvalho de Melo <acme@conectiva.com.br>
Cc: Adrian Bunk <bunk@fs.tum.de>,
	netdev@oss.sgi.com, davem@redhat.com, pekkas@netcore.fi,
	lksctp-developers@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: RFC: [2.6 patch] disallow modular IPv6
Date: Mon, 29 Sep 2003 15:29:26 +0100	[thread overview]
Message-ID: <1064845765.21551.13.camel@hades.cambridge.redhat.com> (raw)
In-Reply-To: <20030929141548.GS1039@conectiva.com.br>

On Mon, 2003-09-29 at 11:15 -0300, Arnaldo Carvalho de Melo wrote:
> > The underlying point being that your static kernel should not change if
> > you change an option from 'n' to 'm'.
> 
> But that will only happen if CONFIG_IPV6_SUPPORT is always enabled, no?

No. It (kernel changing according to 'm' options) happens at the moment,
and it's evil and broken. Adrian proposes that it should not happen at
all.

The suggestion is that if your kernel was built with
'CONFIG_ALLOW_IPV6_SUPPORT=y' then it has all the structures etc. of the
right size, and the tristate option 'CONFIG_IPV6' becomes available. If
you build with 'CONFIG_ALLOW_IPV6_SUPPORT=n' then you cannot build IPv6.

> > It should only affect the kernel image if you change options to/from 'y'.
> 
> That is a good goal, yes, so lets remove all the ifdefs around EXPORT_SYMBOL,
> etc, i.e.: add bloat for the simple case were I want a minimal kernel.

So build with CONFIG_MODULES=n.

> Humm, so the user will have, in this case, these choices:
> 
> 1. "I don't want IPV6 at all, not now, not ever":
> 	CONFIG_IPV6_SUPPORT=N
> 	CONFIG_IPV6=N  (this is implicit as this depends on
> 			CONFIG_IPV6_SUPPORT)
> 	
> 2. "I think I may well want it the future, who knows? but not now...":
> 	CONFIG_IPV6_SUPPORT=Y
> 	CONFIG_IPV6=N
> 	
> 3. "Nah, some of the users of this pre-compiled kernel will need it":
> 	CONFIG_IPV6_SUPPORT=Y
> 	CONFIG_IPV6=M
> 	
> 4. "Yeah, IPV6 is COOL, how can somebody not use this piece of art?":
> 	CONFIG_IPV6_SUPPORT=Y
> 	CONFIG_IPV6=Y
> 
> Isn't this confusing for the I-wanna-triple-my-kernel-performance-by-compiling-
> the-kernel-for-exactly-what-I-have hordes of users?

No. It's very clear. 

But the current situation is confusing, where you set 'CONFIG_IPV6=m'
and 'make modules' to build IPv6 support since it appears to be modular,
and then the module either doesn't load or loads and oopses due to
structures changing in size. 

-- 
dwmw2


  parent reply	other threads:[~2003-09-29 14:29 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 [this message]
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
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=1064845765.21551.13.camel@hades.cambridge.redhat.com \
    --to=dwmw2@infradead.org \
    --cc=acme@conectiva.com.br \
    --cc=bunk@fs.tum.de \
    --cc=davem@redhat.com \
    --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

all inboxes | Powered by JetHome®