On Tue, 30 Sep 2003 08:39:33 +0100
David Woodhouse <dwmw2@xxxxxxxxxxxxx> 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.