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
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=N (this is implicit as this depends on
> 2. "I think I may well want it the future, who knows? but not now...":
> 3. "Nah, some of the users of this pre-compiled kernel will need it":
> 4. "Yeah, IPV6 is COOL, how can somebody not use this piece of art?":
> Isn't this confusing for the
> 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.