All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@conectiva.com.br>
To: Adrian Bunk <bunk@fs.tum.de>
Cc: "David S. Miller" <davem@redhat.com>,
	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 12:04:31 -0300	[thread overview]
Message-ID: <20030930150430.GA2996@conectiva.com.br> (raw)
In-Reply-To: <20030930133729.GJ295@fs.tum.de>

Em Tue, Sep 30, 2003 at 03:37:29PM +0200, Adrian Bunk escreveu:
> On Mon, Sep 29, 2003 at 10:11:29PM -0700, David S. Miller wrote:
> > On Sun, 28 Sep 2003 21:32:30 -0300
> > Arnaldo Carvalho de Melo <acme@conectiva.com.br> wrote:
> > 
> > > Em Mon, Sep 29, 2003 at 02:14:39AM +0200, Adrian Bunk escreveu:
> > > > On Sun, Sep 28, 2003 at 08:39:10PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > What about the following solution (the names and help texts for the
> > > > config options might not be optimal, I hope you understand the
> > > > intention):
> > > > 
> > > > config IPV6_SUPPORT
> > > > 	bool "IPv6 support"
> > > > 
> > > > config IPV6_ENABLE
> > > > 	tristate "enable IPv6"
> > > > 	depends on IPV6_SUPPORT
> > > > 
> > > > IPV6_SUPPORT changes structs etc. and IPV6_ENABLE is responsible for 
> > > > ipv6.o .
> > > 
> > > Humm, and the idea is? This seems confusing, could you elaborate on why such
> > > scheme is a good thing?
> > 
> > I think the idea is totally broken.  At first, Adrian comments that
> > changing the layout of structs based upon a config option is broken,
> > then he proposes a config option that does nothing except change the
> > layout of structures.
> > 
> > The current situation is perfectly fine.
> 
> I did perhaps express my opinion not clearly.
> 
> My personal opinions:
> 
> It's OK that setting an option to y changes structs or whatever else in 
> the kernel.
> 
> It's not OK if adding a module changes the layout of structs compiled 
> into the kernel.
> 
> Modules have many advantages, one advantage is e.g. that they allow 
> generic distribution kernels without resulting in huge kernel images.
> 
> Another advantage is that you can later add modules to a running kernel, 
> you can compile a module for your kernel and insert it without rebooting 
> the machine. This is currently not possible with moduler IPv6.
> 
> That was my personal opinion.
> 
> My opinions seem to be very close to the opinions of David Woodhouse, so 
> there's no need to repeat your discussion.

And just for the record, as a matter of taste I'd like to see all #ifdefs in
structs to disappear, look at what I did to struct sock in 2.5 and look at
struct sock (include/net/sock.h) in 2.4: no #ifdefs where there was a ton,
what I disagree is to make IPV6 not to be built as a module, that would harm
generic kernels, what I said was that this has to be fixed properly, this
requires time and we are too late in 2.6 for such bigger changes, as this is
not just #ifdefs in structs, it is #ifdefs in the IPV4 code, etc.

Lets revisit this in 2.7.

- Arnaldo

For the record: I did an audit in 99% of the headers in the linux source tree,
#ifdefs in structs are mostly just for: CONFIG_PROCFS, DEBUG, NETFILTER and
IPV6, and just a few.

  reply	other threads:[~2003-09-30 14:58 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 [this message]
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=20030930150430.GA2996@conectiva.com.br \
    --to=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.