* RFC: [2.6 patch] disallow modular IPv6 @ 2003-09-28 22:59 Adrian Bunk 2003-09-28 23:18 ` Arnaldo Carvalho de Melo 2003-09-29 6:29 ` Pekka Savola 0 siblings, 2 replies; 44+ messages in thread From: Adrian Bunk @ 2003-09-28 22:59 UTC (permalink / raw) To: netdev, davem, pekkas; +Cc: lksctp-developers, linux-kernel It seems modular IPv6 doesn't work 100% reliable, e.g. after looking at the code it doesn't seem to be a good idea to compile a kernel without IPv6 support and later build and install IPv6 modules. Is there a great need for modular IPv6 or is the patch below to disallow modular IPv6 OK? diffstat output: net/Kconfig | 2 +- net/sctp/Kconfig | 6 ------ 2 files changed, 1 insertion(+), 7 deletions(-) cu Adrian --- linux-2.6.0-test6-full/net/Kconfig.old 2003-09-29 00:53:05.000000000 +0200 +++ linux-2.6.0-test6-full/net/Kconfig 2003-09-29 00:55:55.000000000 +0200 @@ -117,7 +117,7 @@ # IPv6 as module will cause a CRASH if you try to unload it config IPV6 - tristate "The IPv6 protocol (EXPERIMENTAL)" + bool "The IPv6 protocol (EXPERIMENTAL)" depends on INET && EXPERIMENTAL ---help--- This is experimental support for the next version of the Internet --- linux-2.6.0-test6-full/net/sctp/Kconfig.old 2003-09-29 00:50:11.000000000 +0200 +++ linux-2.6.0-test6-full/net/sctp/Kconfig 2003-09-29 00:52:55.000000000 +0200 @@ -5,14 +5,8 @@ menu "SCTP Configuration (EXPERIMENTAL)" depends on INET && EXPERIMENTAL -config IPV6_SCTP__ - tristate - default y if IPV6=n - default IPV6 if IPV6 - config IP_SCTP tristate "The SCTP Protocol (EXPERIMENTAL)" - depends on IPV6_SCTP__ ---help--- Stream Control Transmission Protocol ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 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-29 6:29 ` Pekka Savola 1 sibling, 1 reply; 44+ messages in thread From: Arnaldo Carvalho de Melo @ 2003-09-28 23:18 UTC (permalink / raw) To: Adrian Bunk; +Cc: netdev, davem, pekkas, lksctp-developers, linux-kernel Em Mon, Sep 29, 2003 at 12:59:41AM +0200, Adrian Bunk escreveu: > It seems modular IPv6 doesn't work 100% reliable, e.g. after looking at > the code it doesn't seem to be a good idea to compile a kernel without > IPv6 support and later build and install IPv6 modules. Is there a great > need for modular IPv6 or is the patch below to disallow modular IPv6 OK? Please, don't... We're going in the all modules direction, not the other way around, distro (general purpose) kernels would get big bloat in the static kernel. - Arnaldo ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 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-30 5:09 ` David S. Miller 0 siblings, 2 replies; 44+ messages in thread From: Adrian Bunk @ 2003-09-28 23:24 UTC (permalink / raw) To: Arnaldo Carvalho de Melo, netdev, davem, pekkas, lksctp-developers, linux-kernel On Sun, Sep 28, 2003 at 08:18:42PM -0300, Arnaldo Carvalho de Melo wrote: > Em Mon, Sep 29, 2003 at 12:59:41AM +0200, Adrian Bunk escreveu: > > It seems modular IPv6 doesn't work 100% reliable, e.g. after looking at > > the code it doesn't seem to be a good idea to compile a kernel without > > IPv6 support and later build and install IPv6 modules. Is there a great > > need for modular IPv6 or is the patch below to disallow modular IPv6 OK? > > Please, don't... We're going in the all modules direction, not the other > way around, distro (general purpose) kernels would get big bloat in the > static kernel. E.g. from include/net/tcp.h: <-- snip --> ... struct tcp_skb_cb { union { struct inet_skb_parm h4; #if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE) struct inet6_skb_parm h6; #endif } header; /* For incoming frames */ ... <-- snip --> This is broken since it's legal to compile a module much later than the kernel. If modular IPv6 is allowed, the #if has to be removed, and the struct will be larger in the case IPv6 is never be used. > - Arnaldo cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 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-30 5:09 ` David S. Miller 1 sibling, 2 replies; 44+ messages in thread From: Arnaldo Carvalho de Melo @ 2003-09-28 23:39 UTC (permalink / raw) To: Adrian Bunk; +Cc: netdev, davem, pekkas, lksctp-developers, linux-kernel Em Mon, Sep 29, 2003 at 01:24:03AM +0200, Adrian Bunk escreveu: > On Sun, Sep 28, 2003 at 08:18:42PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Mon, Sep 29, 2003 at 12:59:41AM +0200, Adrian Bunk escreveu: > > > It seems modular IPv6 doesn't work 100% reliable, e.g. after looking at > > > the code it doesn't seem to be a good idea to compile a kernel without > > > IPv6 support and later build and install IPv6 modules. Is there a great > > > need for modular IPv6 or is the patch below to disallow modular IPv6 OK? > > > > Please, don't... We're going in the all modules direction, not the other > > way around, distro (general purpose) kernels would get big bloat in the > > static kernel. > > E.g. from include/net/tcp.h: > > <-- snip --> > > ... > struct tcp_skb_cb { > union { > struct inet_skb_parm h4; > #if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE) > struct inet6_skb_parm h6; > #endif > } header; /* For incoming frames */ > ... > > <-- snip --> > > This is broken since it's legal to compile a module much later than the > kernel. > > If modular IPv6 is allowed, the #if has to be removed, and the struct > will be larger in the case IPv6 is never be used. Its not just this, look at all the CONFIG_IPV6 related #ifdefs in the core tcp/ip v4 code, the point is that this is a (currently) needed limitation to be able to ship a kernel that can be used by both ipv6 users and people that doesn't (yet) need ipv6. Simply removing the ifdefs in the headers will not help, leaving it in the kernel will bloat general purpose kernels, so can we live with this limitation till we sort out the IPV6/IPV4 entanglement in a good way? I.e. lets leave ipv6 as a special case, perhaps just adding a big fat warning in relevant Kconfigs. - Arnaldo ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 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 1 sibling, 0 replies; 44+ messages in thread From: Arnaldo Carvalho de Melo @ 2003-09-28 23:47 UTC (permalink / raw) To: Adrian Bunk, netdev, davem, pekkas, lksctp-developers, linux-kernel Em Sun, Sep 28, 2003 at 08:39:10PM -0300, Arnaldo C. Melo escreveu: > Simply removing the ifdefs in the headers will not help, leaving it in the > kernel will bloat general purpose kernels, so can we live with this limitation s/leaving it in the kernel/making it always statically linked in the kernel if selected/g Sorry... - Arnaldo ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 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 1 sibling, 1 reply; 44+ messages in thread From: Adrian Bunk @ 2003-09-29 0:14 UTC (permalink / raw) To: Arnaldo Carvalho de Melo, netdev, davem, pekkas, lksctp-developers, linux-kernel On Sun, Sep 28, 2003 at 08:39:10PM -0300, Arnaldo Carvalho de Melo wrote: > > Its not just this, look at all the CONFIG_IPV6 related #ifdefs in the core > tcp/ip v4 code, the point is that this is a (currently) needed limitation to be > able to ship a kernel that can be used by both ipv6 users and people that > doesn't (yet) need ipv6. > > Simply removing the ifdefs in the headers will not help, leaving it in the > kernel will bloat general purpose kernels, so can we live with this limitation > till we sort out the IPV6/IPV4 entanglement in a good way? I.e. lets leave ipv6 > as a special case, perhaps just adding a big fat warning in relevant Kconfigs. 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 . > - Arnaldo cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 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-30 5:11 ` David S. Miller 0 siblings, 2 replies; 44+ messages in thread From: Arnaldo Carvalho de Melo @ 2003-09-29 0:32 UTC (permalink / raw) To: Adrian Bunk; +Cc: netdev, davem, pekkas, lksctp-developers, linux-kernel 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? - Arnaldo ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 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-30 5:17 ` David S. Miller 2003-09-30 5:11 ` David S. Miller 1 sibling, 2 replies; 44+ messages in thread From: David Woodhouse @ 2003-09-29 9:02 UTC (permalink / raw) To: Arnaldo Carvalho de Melo Cc: Adrian Bunk, netdev, davem, pekkas, lksctp-developers, linux-kernel On Sun, 2003-09-28 at 21:32 -0300, Arnaldo Carvalho de Melo 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? The idea is that you then have ifdefs on CONFIG_IPV6_SUPPORT not on CONFIG_IPV6_MODULE. The underlying point being that your static kernel should not change if you change an option from 'n' to 'm'. It should only affect the kernel image if you change options to/from 'y'. We should remove the definitions of 'CONFIG_xxxx_MODULE' entirely from visibility during the build of non-module files, to prevent further breakage of this sort. -- dwmw2 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 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 ` (2 more replies) 2003-09-30 5:17 ` David S. Miller 1 sibling, 3 replies; 44+ messages in thread From: Arnaldo Carvalho de Melo @ 2003-09-29 14:15 UTC (permalink / raw) To: David Woodhouse Cc: Adrian Bunk, netdev, davem, pekkas, lksctp-developers, linux-kernel Em Mon, Sep 29, 2003 at 10:02:55AM +0100, David Woodhouse escreveu: > On Sun, 2003-09-28 at 21:32 -0300, Arnaldo Carvalho de Melo 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? > > The idea is that you then have ifdefs on CONFIG_IPV6_SUPPORT not on > CONFIG_IPV6_MODULE. That part I understood :) > 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? > 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. 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? - Arnaldo ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 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 2 siblings, 0 replies; 44+ messages in thread From: Jan Evert van Grootheest @ 2003-09-29 14:28 UTC (permalink / raw) To: Arnaldo Carvalho de Melo; +Cc: netdev, lksctp-developers, linux-kernel Arnaldo, I guess I am one of those I-wanna-triple-my-kernel-performance- by-compiling-the-kernel-for-exactly-what-I-have hordes. Although I don't think it actually triples my kernel performance ))-: Those people anyway recompile the kernel if they want some feature (un)included. And I'd say RTM (ah, that should be RTH -- Read The Help) if they don't understand it. It's what I do. I would expect those that know enough to reconfigure the kernel also know enough to understand the help that will undoubtedly be provided with this option? -- Jan Evert Arnaldo Carvalho de Melo wrote: > Em Mon, Sep 29, 2003 at 10:02:55AM +0100, David Woodhouse escreveu: >>On Sun, 2003-09-28 at 21:32 -0300, Arnaldo Carvalho de Melo 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? >> >>The idea is that you then have ifdefs on CONFIG_IPV6_SUPPORT not on >>CONFIG_IPV6_MODULE. > > > That part I understood :) > > >>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? > > >>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. > > 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? > > - Arnaldo > - > 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/ > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 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 2 siblings, 0 replies; 44+ messages in thread From: David Woodhouse @ 2003-09-29 14:29 UTC (permalink / raw) To: Arnaldo Carvalho de Melo Cc: Adrian Bunk, netdev, davem, pekkas, lksctp-developers, linux-kernel 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 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 2 siblings, 1 reply; 44+ messages in thread From: Valdis.Kletnieks @ 2003-09-29 14:38 UTC (permalink / raw) To: Arnaldo Carvalho de Melo Cc: David Woodhouse, Adrian Bunk, netdev, davem, pekkas, lksctp-developers, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1058 bytes --] On Mon, 29 Sep 2003 11:15:48 -0300, Arnaldo Carvalho de Melo said: > 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, this is the behavior we want, and we can write Kconfig help entries that explain it. Anybody want to do a sanity check against CONFIG_IP6_NF_IPTABLES - that looks like another gotcha if it isn't implemented properly (it may be, I just haven't actually looked it over)? [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-29 14:38 ` Valdis.Kletnieks @ 2003-09-29 14:46 ` David Woodhouse 0 siblings, 0 replies; 44+ messages in thread From: David Woodhouse @ 2003-09-29 14:46 UTC (permalink / raw) To: Valdis.Kletnieks Cc: Arnaldo Carvalho de Melo, Adrian Bunk, netdev, davem, pekkas, lksctp-developers, linux-kernel On Mon, 2003-09-29 at 10:38 -0400, Valdis.Kletnieks@vt.edu wrote: > No, this is the behavior we want, and we can write Kconfig help entries that > explain it. > > Anybody want to do a sanity check against CONFIG_IP6_NF_IPTABLES - that > looks like another gotcha if it isn't implemented properly (it may be, I just haven't > actually looked it over)? In 2.7 we really should just stop the CONFIG_xxx_MODULE definitions being available during builds of the static kernel. -- dwmw2 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-29 9:02 ` David Woodhouse 2003-09-29 14:15 ` Arnaldo Carvalho de Melo @ 2003-09-30 5:17 ` David S. Miller 2003-09-30 6:31 ` David Woodhouse 1 sibling, 1 reply; 44+ messages in thread From: David S. Miller @ 2003-09-30 5:17 UTC (permalink / raw) To: David Woodhouse Cc: acme, bunk, netdev, pekkas, lksctp-developers, linux-kernel On Mon, 29 Sep 2003 10:02:55 +0100 David Woodhouse <dwmw2@infradead.org> wrote: > The underlying point being that your static kernel should not change if > you change an option from 'n' to 'm'. It should only affect the kernel > image if you change options to/from 'y'. I totally disagree, what ipv6 is doing is perfectly fine. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-30 5:17 ` David S. Miller @ 2003-09-30 6:31 ` David Woodhouse 2003-10-01 19:47 ` Guennadi Liakhovetski 0 siblings, 1 reply; 44+ messages in thread From: David Woodhouse @ 2003-09-30 6:31 UTC (permalink / raw) To: David S. Miller Cc: acme, bunk, netdev, pekkas, lksctp-developers, linux-kernel On Mon, 2003-09-29 at 22:17 -0700, David S. Miller wrote: > On Mon, 29 Sep 2003 10:02:55 +0100 > David Woodhouse <dwmw2@infradead.org> wrote: > > > The underlying point being that your static kernel should not change if > > you change an option from 'n' to 'm'. It should only affect the kernel > > image if you change options to/from 'y'. > > I totally disagree, what ipv6 is doing is perfectly fine. Your right. -- dwmw2 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-30 6:31 ` David Woodhouse @ 2003-10-01 19:47 ` Guennadi Liakhovetski 0 siblings, 0 replies; 44+ messages in thread From: Guennadi Liakhovetski @ 2003-10-01 19:47 UTC (permalink / raw) To: David Woodhouse Cc: David S. Miller, acme, bunk, netdev, pekkas, lksctp-developers, linux-kernel On Tue, 30 Sep 2003, David Woodhouse wrote: > On Mon, 2003-09-29 at 22:17 -0700, David S. Miller wrote: > > On Mon, 29 Sep 2003 10:02:55 +0100 > > David Woodhouse <dwmw2@infradead.org> wrote: > > > > > The underlying point being that your static kernel should not change if > > > you change an option from 'n' to 'm'. It should only affect the kernel > > > image if you change options to/from 'y'. > > > > I totally disagree, what ipv6 is doing is perfectly fine. > > Your right. Well, maybe you are right, but I certainly liked the feature, that I could just add a module to a currently running kernel's configuration, compile and insmod it. But, if this is how it is (going to be) now - that one shouldn't rely on this, do you agree, that such attempts should be stopped by the build system? If so, I think, a script, trying to find possible problems could be of help? It wouldn't be trivial, but maybe there's already framework available, that can be taught to do this? Ideally, you would want to check: for each tristate CONFIG_ find from the respective Makefile(s) which source (*.[Sc])-files are involved with obj-$(CONFIG_x). Find depending source-files from "depends on x" in respective Kconfig recursively. If CONFIG_x appears in any other source-files - it is already a (likely) problem. Now headers. Well, if we want to check infinitely deep inclusions - it would require a fat cluster / SMP, I guess:-) So, is there a piece of software among all automatic checkers, that could be relatively easily taught to do this and would it make sense to run such a check on each -pre and -rc version? Actually, is anybody checking for recursive includes? Guennadi --- Guennadi Liakhovetski ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-29 0:32 ` Arnaldo Carvalho de Melo 2003-09-29 9:02 ` David Woodhouse @ 2003-09-30 5:11 ` David S. Miller 2003-09-30 13:37 ` Adrian Bunk 1 sibling, 1 reply; 44+ messages in thread From: David S. Miller @ 2003-09-30 5:11 UTC (permalink / raw) To: Arnaldo Carvalho de Melo Cc: bunk, netdev, pekkas, lksctp-developers, linux-kernel 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-30 5:11 ` David S. Miller @ 2003-09-30 13:37 ` Adrian Bunk 2003-09-30 15:04 ` Arnaldo Carvalho de Melo 0 siblings, 1 reply; 44+ messages in thread From: Adrian Bunk @ 2003-09-30 13:37 UTC (permalink / raw) To: David S. Miller Cc: Arnaldo Carvalho de Melo, netdev, pekkas, lksctp-developers, linux-kernel 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. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-30 13:37 ` Adrian Bunk @ 2003-09-30 15:04 ` Arnaldo Carvalho de Melo 2003-10-01 6:39 ` David S. Miller 0 siblings, 1 reply; 44+ messages in thread From: Arnaldo Carvalho de Melo @ 2003-09-30 15:04 UTC (permalink / raw) To: Adrian Bunk Cc: David S. Miller, netdev, pekkas, lksctp-developers, linux-kernel 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-30 15:04 ` Arnaldo Carvalho de Melo @ 2003-10-01 6:39 ` David S. Miller 0 siblings, 0 replies; 44+ messages in thread From: David S. Miller @ 2003-10-01 6:39 UTC (permalink / raw) To: Arnaldo Carvalho de Melo Cc: bunk, netdev, pekkas, lksctp-developers, linux-kernel On Tue, 30 Sep 2003 12:04:31 -0300 Arnaldo Carvalho de Melo <acme@conectiva.com.br> wrote: > 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, I totally agree with this. It would make the structs that actually get used smaller in fact. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-28 23:24 ` Adrian Bunk 2003-09-28 23:39 ` Arnaldo Carvalho de Melo @ 2003-09-30 5:09 ` David S. Miller 2003-09-30 6:32 ` David Woodhouse 1 sibling, 1 reply; 44+ messages in thread From: David S. Miller @ 2003-09-30 5:09 UTC (permalink / raw) To: Adrian Bunk; +Cc: acme, netdev, pekkas, lksctp-developers, linux-kernel On Mon, 29 Sep 2003 01:24:03 +0200 Adrian Bunk <bunk@fs.tum.de> wrote: > This is broken since it's legal to compile a module much later than the > kernel. Not in this case. For things inside the kernel, what ipv6 is doing is completely legal. Changing your config setting in any way in the main kernel tree can change just about anything else in the kernel, including the layout of structures. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-30 5:09 ` David S. Miller @ 2003-09-30 6:32 ` David Woodhouse 2003-09-30 7:03 ` David S. Miller 0 siblings, 1 reply; 44+ messages in thread From: David Woodhouse @ 2003-09-30 6:32 UTC (permalink / raw) To: David S. Miller Cc: Adrian Bunk, acme, netdev, pekkas, lksctp-developers, linux-kernel On Mon, 2003-09-29 at 22:09 -0700, David S. Miller wrote: > For things inside the kernel, what ipv6 is doing is completely legal. > Changing your config setting in any way in the main kernel tree can > change just about anything else in the kernel, including the layout > of structures. With boolean options that's fair enough. But changing any config option from 'n' to 'm' should not change anything in the main kernel. To do so is confusing and should be considered broken, as Adrian says. -- dwmw2 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-30 6:32 ` David Woodhouse @ 2003-09-30 7:03 ` David S. Miller 2003-09-30 7:39 ` David Woodhouse 0 siblings, 1 reply; 44+ messages in thread From: David S. Miller @ 2003-09-30 7:03 UTC (permalink / raw) To: David Woodhouse Cc: bunk, acme, netdev, pekkas, lksctp-developers, linux-kernel On Tue, 30 Sep 2003 07:32:42 +0100 David Woodhouse <dwmw2@infradead.org> wrote: > On Mon, 2003-09-29 at 22:09 -0700, David S. Miller wrote: > > For things inside the kernel, what ipv6 is doing is completely legal. > > Changing your config setting in any way in the main kernel tree can > > change just about anything else in the kernel, including the layout > > of structures. > > With boolean options that's fair enough. But changing any config option > from 'n' to 'm' should not change anything in the main kernel. To do so > is confusing and should be considered broken, as Adrian says. This conflicts with the other reply you've made to me in this thread where you say that you agree with me. So which is it? :-) I don't see why "enabling to 'y'" and "enabling to 'm'" are in any way fundamentally different. You're turning something on, therefore something is going to change. And when I see suggestions that we add four options to replace the single one we have now, with a addendum saying "it's not really complex, we'll explain it in the documentation", I want to pull my hair out. I would rather apply a patch that bloats up the structures than subscribe to crazy ideas such as this four option one being proposed. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-30 7:03 ` David S. Miller @ 2003-09-30 7:39 ` David Woodhouse 2003-09-30 8:08 ` David S. Miller 0 siblings, 1 reply; 44+ messages in thread From: David Woodhouse @ 2003-09-30 7:39 UTC (permalink / raw) To: David S. Miller Cc: bunk, acme, netdev, pekkas, lksctp-developers, linux-kernel On Tue, 2003-09-30 at 00:03 -0700, David S. Miller wrote: > This conflicts with the other reply you've made to me in this > thread where you say that you agree with me. > > So which is it? :-) Sorry, I was having a laugh. It amused me to demonstrate how a single apostrophe, or lack of it, can entirely change the meaning of a sentence. I didn't expect you personally to fall for it -- I expected you to give me more credit than to assume I'd make kindergarten errors in a two-word email. Read it again, only this time bear in mind I'm a native English speaker with an IQ over 50 :) > I don't see why "enabling to 'y'" and "enabling to 'm'" are in any > way fundamentally different. You're turning something on, therefore > something is going to change. And you don't see why it's confusing that turning something on as a _module_ changes the contents of the kernel image? 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. We should strive to keep this true. > And when I see suggestions that we add four options to replace the > single one we have now, with a addendum saying "it's not really > complex, we'll explain it in the documentation", I want to pull my > hair out. It was two options, giving four potential combinations. They were simple: Allow this kernel to ever support IPv6? Y/N Build IPv6 support? Y/M/N -- dwmw2 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 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 12:06 ` Olivier Galibert 0 siblings, 2 replies; 44+ messages in thread From: David S. Miller @ 2003-09-30 8:08 UTC (permalink / raw) To: David Woodhouse Cc: bunk, acme, netdev, pekkas, lksctp-developers, linux-kernel 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 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 14:21 ` Theodore Ts'o 2003-09-30 12:06 ` Olivier Galibert 1 sibling, 2 replies; 44+ messages in thread From: David Woodhouse @ 2003-09-30 8:26 UTC (permalink / raw) To: David S. Miller Cc: bunk, acme, netdev, pekkas, lksctp-developers, linux-kernel On Tue, 2003-09-30 at 01:08 -0700, David S. Miller wrote: > 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. Why would he run 'make'? He'll only run 'make modules' since he only enabled one extra module, and then he expects to be able to load it without a reboot. He expects this because it is intuitive ('just a new module') and because it is true for just about all other modular options in the tree. > 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. -- dwmw2 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 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 15:13 ` Richard Guy Briggs 2003-09-30 14:21 ` Theodore Ts'o 1 sibling, 2 replies; 44+ messages in thread From: David S. Miller @ 2003-09-30 8:30 UTC (permalink / raw) To: David Woodhouse Cc: bunk, acme, netdev, pekkas, lksctp-developers, linux-kernel On Tue, 30 Sep 2003 09:26:38 +0100 David Woodhouse <dwmw2@infradead.org> wrote: > Why would he run 'make'? He'll only run 'make modules' since he only > enabled one extra module, and then he expects to be able to load it > without a reboot. If 'make modules' doesn't check if the config change has hit a dependency that requires the core kernel image to be rebuilt, we need to fix that. 'make modules' depends upon the kernel image. At the very least, it should refuse to build the modules and tell the user what he needs to do first. All you've shown me is a bug in the build system, not a fundamental issue with module enables creating changes to the main kernel image. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 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 15:13 ` Richard Guy Briggs 1 sibling, 1 reply; 44+ messages in thread From: David Woodhouse @ 2003-09-30 8:42 UTC (permalink / raw) To: David S. Miller Cc: bunk, acme, netdev, pekkas, lksctp-developers, linux-kernel On Tue, 2003-09-30 at 01:30 -0700, David S. Miller wrote: > If 'make modules' doesn't check if the config change has hit a > dependency that requires the core kernel image to be rebuilt, we need > to fix that. 'make modules' depends upon the kernel image. 'make modules' should make the modules. If for some reason this really does require the core kernel image to be present and up to date, perhaps for modversions, then I agree that it should also rebuild the core kernel. If there's no actual dependency on the core kernel image, however, then it should not be rebuilt for 'make modules'. If 'make modules' was equivalent to 'make all' then it should not exist at all. Consider the case where you run a distribution kernel but wish to compile a couple of extra modules for esoteric hardware, file systems or protocols. Why would you want 'make modules' to rebuild the kernel image? The one you're already running is just fine. Besides, the whole question is mostly is orthogonal to the assertion that a config change from 'n' to 'm' should not effect changes in the core kernel. -- dwmw2 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-30 8:42 ` David Woodhouse @ 2003-09-30 8:51 ` David S. Miller 2003-09-30 9:14 ` David Woodhouse 0 siblings, 1 reply; 44+ messages in thread From: David S. Miller @ 2003-09-30 8:51 UTC (permalink / raw) To: David Woodhouse Cc: bunk, acme, netdev, pekkas, lksctp-developers, linux-kernel On Tue, 30 Sep 2003 09:42:41 +0100 David Woodhouse <dwmw2@infradead.org> wrote: > 'make modules' should make the modules. If for some reason this really > does require the core kernel image to be present and up to date, perhaps > for modversions, then I agree that it should also rebuild the core > kernel. So it's OK for modversions to make modules depend upon the main kernel image, but it's not OK for ipv6 to do the same exact thing. Is this what you're saying? > If there's no actual dependency on the core kernel image, however, then > it should not be rebuilt for 'make modules'. If 'make modules' was > equivalent to 'make all' then it should not exist at all. I don't see how you can say that modversions can create this module dependency upon the kernel image, but ipv6 is not allowed to. And this doesn't turn 'make modules' into the same thing as 'make all'. It will still behave differently in a lot of situations. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 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 0 siblings, 2 replies; 44+ messages in thread From: David Woodhouse @ 2003-09-30 9:14 UTC (permalink / raw) To: David S. Miller Cc: bunk, acme, netdev, pekkas, lksctp-developers, linux-kernel On Tue, 2003-09-30 at 01:51 -0700, David S. Miller wrote: > So it's OK for modversions to make modules depend upon the main kernel > image, but it's not OK for ipv6 to do the same exact thing. Is this > what you're saying? Not at all. You're talking about something entirely different. We are not talking about _changing_ the value of $CONFIG_MODVERSIONS. CONFIG_MODVERSIONS is a boolean option, and of _course_ changing it from 'n' to 'y' should change the core kernel. Your 'dependency on modversions' is entirely unrelated to any changes in .config. In the 2.4 kernel you needed to run 'make dep', which had the side-effect of creating all the version strings which were required to make any modules. In the 2.6 kernel, I suspect that these same version strings are now produced as a side-effect of the 'make vmlinux' stage, and hence that it's required to 'make vmlinux' before any modules can be built. This (potential) dependency is entirely unrelated to any _changes_ in configuration. It would be optimal to be able to build modules _without_ actually having to build the kernel image, but if that dependency exists due to the current build mechanism, then it would be a bug for 'make modules' to refrain from also building vmlinux. It was offered as an example of a case in which your assertion would be correct; that 'make modules' should also rebuild vmlinux. I'm sorry if it caused confusion -- I should probably not have followed your digression. > > If there's no actual dependency on the core kernel image, however, then > > it should not be rebuilt for 'make modules'. If 'make modules' was > > equivalent to 'make all' then it should not exist at all. > > I don't see how you can say that modversions can create this module > dependency upon the kernel image, but ipv6 is not allowed to. There is no inconsistency. It's very simple: ∃ configuration option CONFIG_xxx : Changing CONFIG_xxx from 'n' to 'y' may change the resulting vmlinux. Changing CONFIG_xxx from 'n' to 'm' should not do so. -- dwmw2 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-30 9:14 ` David Woodhouse @ 2003-09-30 9:17 ` David Woodhouse 2003-09-30 9:24 ` David S. Miller 1 sibling, 0 replies; 44+ messages in thread From: David Woodhouse @ 2003-09-30 9:17 UTC (permalink / raw) To: David S. Miller Cc: bunk, acme, netdev, pekkas, lksctp-developers, linux-kernel On Tue, 2003-09-30 at 10:14 +0100, David Woodhouse wrote: > ∃ configuration option CONFIG_xxx : > Changing CONFIG_xxx from 'n' to 'y' may change the resulting vmlinux. > Changing CONFIG_xxx from 'n' to 'm' should not do so. Bah. s/∃/∀/ of course. I should set up key bindings rather than having to cut and paste with a mouse and insufficient caffeine :) -- dwmw2 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 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 ` (3 more replies) 1 sibling, 4 replies; 44+ messages in thread From: David S. Miller @ 2003-09-30 9:24 UTC (permalink / raw) To: David Woodhouse Cc: bunk, acme, netdev, pekkas, lksctp-developers, linux-kernel On Tue, 30 Sep 2003 10:14:02 +0100 David Woodhouse <dwmw2@infradead.org> wrote: > Not at all. You're talking about something entirely different. I think they are the same. It's module building depending upon the kernel image being up to date. modules: vmlinux image ... blah blah blah or however you want to express it in the makefiles. > In the 2.6 kernel, I suspect that these same version strings are now > produced as a side-effect of the 'make vmlinux' stage, and hence that > it's required to 'make vmlinux' before any modules can be built. 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. > This (potential) dependency is entirely unrelated to any _changes_ in > configuration. I don't see how this changes the argument I'm trying to make. I'm saying that either you accept that the kernel image must be uptodate in order to build modules, or you don't. It doesn't matter what creates that dependency. You can't say "the ipv6 thing is different because a config change from 'n' to 'm' is creating the dependency", that doesn't make it special. In all such cases, modules require the kernel image they are being built for to be uptodate. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-30 9:24 ` David S. Miller @ 2003-09-30 9:57 ` Sam Ravnborg 2003-09-30 10:02 ` David Woodhouse ` (2 subsequent siblings) 3 siblings, 0 replies; 44+ messages in thread From: Sam Ravnborg @ 2003-09-30 9:57 UTC (permalink / raw) To: David S. Miller Cc: David Woodhouse, bunk, acme, netdev, pekkas, lksctp-developers, linux-kernel On Tue, Sep 30, 2003 at 02:24:10AM -0700, David S. Miller wrote: > > > In the 2.6 kernel, I suspect that these same version strings are now > > produced as a side-effect of the 'make vmlinux' stage, and hence that > > it's required to 'make vmlinux' before any modules can be built. > > 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. There is a postprocessing step when building modules that take care of modversioning. And yes, it requires a final vmlinux. Sam ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 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 11:39 ` Sam Ravnborg 2003-09-30 13:44 ` Dana Lacoste 2003-09-30 13:50 ` Kai Germaschewski 3 siblings, 2 replies; 44+ messages in thread From: David Woodhouse @ 2003-09-30 10:02 UTC (permalink / raw) To: David S. Miller Cc: bunk, acme, netdev, pekkas, lksctp-developers, linux-kernel On Tue, 2003-09-30 at 02:24 -0700, David S. Miller wrote: > I think they are the same. It's module building depending upon the > kernel image being up to date. > > modules: vmlinux image > ... blah blah blah > > or however you want to express it in the makefiles. In the case of modversions, we are talking about the fact that it may be physically _impossible_ to build a module referencing an in-kernel symbol, if the checksum required for that symbol -- the 'version string' -- is not yet calculated. If the version strings are generated as a side-effect of compiling the files which actually export the symbols in question, then it's necessary to do that before building any module which attempts to use those symbols. Note that it's not actually necessary to provide a vmlinux file, nor to do any linking. It's only necessary to perform those steps which produce the version strings for those symbols actually referenced by the modules which are being built. That is the requirement for correctness from the makefiles; nothing more. Of course it's usually considered acceptable for the makefiles to recompile _more_ than is necessary, so your way of expressing it above could indeed be a first, extremely suboptimal, attempt at a 'fix' if the build is indeed currently broken in the way that you suggest. > I don't see how this changes the argument I'm trying to make. > > I'm saying that either you accept that the kernel image must be > uptodate in order to build modules, or you don't. It doesn't matter > what creates that dependency. I agree with your assertion -- it is true that I either accept that fact or I don't. Furthermore, I agree that if it is physically necessary for the kernel image to be up to date in order to build modules, then it would be a bug for the build system not to do so. That is all irrelevant to the question which started this thread though. That would be correctly stated as follows: I am saying that even if I run 'make all', I do not accept that the resulting kernel image should be _different_ when I change any option from 'n' to 'm'. -- dwmw2 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 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 1 sibling, 1 reply; 44+ messages in thread From: David S. Miller @ 2003-09-30 10:01 UTC (permalink / raw) To: David Woodhouse Cc: bunk, acme, netdev, pekkas, lksctp-developers, linux-kernel On Tue, 30 Sep 2003 11:02:49 +0100 David Woodhouse <dwmw2@infradead.org> wrote: > I am saying that even if I run 'make all', I do not accept that the > resulting kernel image should be _different_ when I change any option > from 'n' to 'm'. Then let's agree to disagree. Send the proposal to Linus and let him hash it out with you, although I belive I have a good idea which side of the fence he'll be on. 8-) ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-30 10:01 ` David S. Miller @ 2003-09-30 10:14 ` David Woodhouse 0 siblings, 0 replies; 44+ messages in thread From: David Woodhouse @ 2003-09-30 10:14 UTC (permalink / raw) To: David S. Miller Cc: bunk, acme, netdev, pekkas, lksctp-developers, linux-kernel On Tue, 2003-09-30 at 03:01 -0700, David S. Miller wrote: > Then let's agree to disagree. That's what I suggested 50 minutes ago :) As I said, it's a matter of taste. The idea that CONFIG_xxx_MODULE should be removed from visibility during the vmlinux build is not limited to myself and Adrian alone. We can revisit it during 2.7 development. I won't be spending time on it myself at least until after sleep_on() is already dead, but I'm sure someone will offer it as a 'cleanup'. -- dwmw2 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-30 10:02 ` David Woodhouse 2003-09-30 10:01 ` David S. Miller @ 2003-09-30 11:39 ` Sam Ravnborg 1 sibling, 0 replies; 44+ messages in thread From: Sam Ravnborg @ 2003-09-30 11:39 UTC (permalink / raw) To: David Woodhouse Cc: David S. Miller, bunk, acme, netdev, pekkas, lksctp-developers, linux-kernel On Tue, Sep 30, 2003 at 11:02:49AM +0100, David Woodhouse wrote: > On Tue, 2003-09-30 at 02:24 -0700, David S. Miller wrote: > > I think they are the same. It's module building depending upon the > > kernel image being up to date. > > > > modules: vmlinux image > > ... blah blah blah > > > > or however you want to express it in the makefiles. > > In the case of modversions, we are talking about the fact that it may be > physically _impossible_ to build a module referencing an in-kernel > symbol, if the checksum required for that symbol -- the 'version string' > -- is not yet calculated. If the version strings are generated as a > side-effect of compiling the files which actually export the symbols in > question, then it's necessary to do that before building any module > which attempts to use those symbols. The version strings are made from info obtained from vmlinux and the *.o files. So vmlinux is a prerequisite to calculate the version string. And to get vmlinux you need to build the kernel. And the build system will check all dependencies when it needs vmlinux. > Note that it's not actually necessary to provide a vmlinux file, nor to > do any linking. It's only necessary to perform those steps which produce > the version strings for those symbols actually referenced by the modules > which are being built. Which require vmlinux and other module.o files. > That is the requirement for correctness from the makefiles; nothing > more. Of course it's usually considered acceptable for the makefiles to > recompile _more_ than is necessary I would like to know if there exists any cases where _more_ (or less) is being build. Mostly I consider it a bug in such case, but there are a few corner cases. [Only commenting on the kbuild side of things - I'm not trying to be involved in the other part of the discussion ;-)] Sam ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 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 13:44 ` Dana Lacoste 2003-09-30 13:50 ` Kai Germaschewski 3 siblings, 0 replies; 44+ messages in thread From: Dana Lacoste @ 2003-09-30 13:44 UTC (permalink / raw) To: David S. Miller; +Cc: David Woodhouse, netdev, lksctp-developers, linux-kernel 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-30 9:24 ` David S. Miller ` (2 preceding siblings ...) 2003-09-30 13:44 ` Dana Lacoste @ 2003-09-30 13:50 ` Kai Germaschewski 3 siblings, 0 replies; 44+ messages in thread From: Kai Germaschewski @ 2003-09-30 13:50 UTC (permalink / raw) To: David S. Miller Cc: David Woodhouse, bunk, acme, netdev, pekkas, lksctp-developers, linux-kernel On Tue, 30 Sep 2003, David S. Miller wrote: > I think they are the same. It's module building depending upon the > kernel image being up to date. > > modules: vmlinux image > ... blah blah blah > > or however you want to express it in the makefiles. I strongly disagree with this. What the makefiles currently do is correct, i.e. if you "make modules" you'll only get updated modules, you didn't ask for an updated vmlinux, and so you don't get it. The module you get is built correctly, i.e. you'd get the same result if you had rebuilt vmlinux before, since the building of the module does not depend on a "correct" vmlinux at all. If in just about any project you type "make some_object.o", you don't expect make to recompile and rebuild the rest of the project, either, you ask it to 'make' something, and will build exactly that something and the prerequisites necessary to get it right. A sidenote is that if you are using modversions, building the modules correctly needs versioning information from vmlinux, so in that case we need vmlinux to be up-to-date. And that's why in this case vmlinux will be rebuilt first (if something changed) - otherwise the modules you were asking for wouldn't be correct. But the fact the you get an updated vmlinux is just a side-effect, you didn't ask for it, and thus you can't rely on it. Think about the meaning of "make". With respect to the actual discussion, my opinion is that it's desirable to have the core kernel not change depending on whether or not something is compiled modular, but I believe there are cases which justify an exception, and IPv6 seems to be one of them. Modversions will catch this and prevent the user from inserting the module and accidentally crash the system, so I think it's all fine. --Kai ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-30 8:30 ` David S. Miller 2003-09-30 8:42 ` David Woodhouse @ 2003-09-30 15:13 ` Richard Guy Briggs 1 sibling, 0 replies; 44+ messages in thread From: Richard Guy Briggs @ 2003-09-30 15:13 UTC (permalink / raw) To: netdev, linux-kernel On Tue, Sep 30, 2003 at 01:30:25AM -0700, David S. Miller wrote: > On Tue, 30 Sep 2003 09:26:38 +0100 > David Woodhouse <dwmw2@infradead.org> wrote: > > > Why would he run 'make'? He'll only run 'make modules' since he only > > enabled one extra module, and then he expects to be able to load it > > without a reboot. > > If 'make modules' doesn't check if the config change has hit a > dependency that requires the core kernel image to be rebuilt, we need > to fix that. 'make modules' depends upon the kernel image. If a module depends on core kernel functionality, that module option should not be visible in the config until the core kernel functionality has been turned on. Otherwise, maybe that core kernel functionality should also be a module. > At the very least, it should refuse to build the modules and tell the > user what he needs to do first. That would also work. > All you've shown me is a bug in the build system, not a fundamental > issue with module enables creating changes to the main kernel image. slainte mhath, RGB -- Richard Guy Briggs -- ~\ Auto-Free Ottawa! Canada <www.TriColour.net> -- \@ @ <www.flora.org/afo/> No Internet Wiretapping! -- _\\/\%___\\/\% Vote! -- <Green.ca> <www.FreeSWAN.org>_______GTVS6#790__(*)_______(*)(*)_______<www.Marillion.com> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-30 8:26 ` David Woodhouse 2003-09-30 8:30 ` David S. Miller @ 2003-09-30 14:21 ` Theodore Ts'o 2003-09-30 14:51 ` David Woodhouse 1 sibling, 1 reply; 44+ messages in thread From: Theodore Ts'o @ 2003-09-30 14:21 UTC (permalink / raw) To: David Woodhouse Cc: David S. Miller, bunk, acme, netdev, pekkas, lksctp-developers, linux-kernel 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-30 14:21 ` Theodore Ts'o @ 2003-09-30 14:51 ` David Woodhouse 0 siblings, 0 replies; 44+ messages in thread From: David Woodhouse @ 2003-09-30 14:51 UTC (permalink / raw) To: Theodore Ts'o Cc: David S. Miller, bunk, acme, netdev, pekkas, lksctp-developers, linux-kernel On Tue, 2003-09-30 at 10:21 -0400, Theodore Ts'o wrote: > 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. It would be difficult to have an opinion on the matter without agreeing with one of us :) > the user may > have a really hard time figuring out that CONFIG_infrastructure is the > way to make a particular device driver appear. To take your chosen example of CONFIG_NET_RADIO.... if your user cannot determine that in order to enable support for her WaveLAN card she must first enable the option marked "Wireless LAN drivers (non-hamradio) & Wireless Extensions" then I respectfully suggest that you quietly take her out back and shoot her. > 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. Unlike the approach taken by your example. Note that in that particular case we'd probably have the 'guard' option "Wireless LAN drivers" _anyway_, even if nothing at _all_ depends upon it other than configuration options. Just like we have CONFIG_NET_ETHERNET, CONFIG_NET_VENDOR_3COM, CONFIG_NET_ISA, CONFIG_NET_PCI and other similar options to keep the config sane. Such 'infrastructure' options, whether they actually make a difference to the resulting kernel or not, are perfectly normal, acceptable and understandable. -- dwmw2 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 2003-09-30 8:08 ` David S. Miller 2003-09-30 8:26 ` David Woodhouse @ 2003-09-30 12:06 ` Olivier Galibert 1 sibling, 0 replies; 44+ messages in thread From: Olivier Galibert @ 2003-09-30 12:06 UTC (permalink / raw) To: David S. Miller Cc: David Woodhouse, bunk, acme, netdev, pekkas, lksctp-developers, linux-kernel On Tue, Sep 30, 2003 at 01:08:55AM -0700, David S. Miller wrote: > On Tue, 30 Sep 2003 08:39:33 +0100 > David Woodhouse <dwmw2@infradead.org> wrote: > > 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. By me for instance. I'm used to modules having no influence until loaded, even at compilation time. I'm used to in-tree and out-of-tree modules to have exactly the same status (ignoring the binary-only modules crap). > > 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. I suspect what you _really_ want is a "disable ipv6 entirely" depending on CONFIG_EMBEDDED which would remove the then bloat. Normal users would never see it and the meaning would be obvious for the ones who care. OG. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: RFC: [2.6 patch] disallow modular IPv6 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-29 6:29 ` Pekka Savola 1 sibling, 0 replies; 44+ messages in thread From: Pekka Savola @ 2003-09-29 6:29 UTC (permalink / raw) To: Adrian Bunk; +Cc: netdev, davem, lksctp-developers, linux-kernel On Mon, 29 Sep 2003, Adrian Bunk wrote: > It seems modular IPv6 doesn't work 100% reliable, e.g. after looking at > the code it doesn't seem to be a good idea to compile a kernel without > IPv6 support and later build and install IPv6 modules. Is there a great > need for modular IPv6 or is the patch below to disallow modular IPv6 OK? IPv6 modularity is critical for all the Linux distributions who wish to give the users the possibility to turn on IPv6 if they wish, but turning it on by default for everybody is not realistic. IMHO, making it non-modular is *NOT* an option. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2003-10-01 19:57 UTC | newest] Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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).