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
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
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
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
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
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
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
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
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
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
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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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)?
On Mon, 2003-09-29 at 10:38 -0400, [email protected] 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
On Mon, 29 Sep 2003 01:24:03 +0200
Adrian Bunk <[email protected]> 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.
On Mon, 29 Sep 2003 10:02:55 +0100
David Woodhouse <[email protected]> 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.
On Sun, 28 Sep 2003 21:32:30 -0300
Arnaldo Carvalho de Melo <[email protected]> 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.
On Mon, 2003-09-29 at 22:17 -0700, David S. Miller wrote:
> On Mon, 29 Sep 2003 10:02:55 +0100
> David Woodhouse <[email protected]> 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
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
On Tue, 30 Sep 2003 07:32:42 +0100
David Woodhouse <[email protected]> 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.
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
On Tue, 30 Sep 2003 08:39:33 +0100
David Woodhouse <[email protected]> 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.
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
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
On Tue, 30 Sep 2003 09:26:38 +0100
David Woodhouse <[email protected]> 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.
On Tue, 30 Sep 2003 09:42:41 +0100
David Woodhouse <[email protected]> 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.
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
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
On Tue, 30 Sep 2003 10:14:02 +0100
David Woodhouse <[email protected]> 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.
On Tue, 30 Sep 2003 11:02:49 +0100
David Woodhouse <[email protected]> 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-)
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
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
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
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
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 <[email protected]> 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.
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 <[email protected]> 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
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
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
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
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
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 <[email protected]> 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.
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 <[email protected]> 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
<http://www.TriColour.net> -- \@ @ <http://www.flora.org/afo/>
No Internet Wiretapping! -- _\\/\%___\\/\% Vote! -- <Green.ca>
<http://www.FreeSWAN.org>_______GTVS6#790__(*)_______(*)(*)_______<www.Marillion.com>