On Oct 10, 2009, at 7:38 AM, Julius Volz wrote:
On Sat, Oct 10, 2009 at 4:03 PM, Allen Parker <parker@xxxxxxxxxxx>
Unless there's a very good reason to exclude CONFIG_IPV6=m from
CONFIG_IPVS_IPV6, you probably shouldn't do it. This patch fixes the
"hidden" IPVS_IPV6 when IPV6=m.
diff -Nur linux-22.214.171.124/net/netfilter/ipvs/Kconfig
--- linux-126.96.36.199/net/netfilter/ipvs/Kconfig 2009-10-10
+++ linux-188.8.131.52-fixed/net/netfilter/ipvs/Kconfig 2009-10-10
@@ -26,7 +26,7 @@
bool "IPv6 support for IPVS"
- depends on EXPERIMENTAL && (IPV6 = y|| IP_VS = IPV6)
+ depends on EXPERIMENTAL && (IPV6 || IP_VS = IPV6)
Add IPv6 support to IPVS. This is incomplete and might be
The problem is that IP_VS_IPV6 doesn't support modularity, so it has
to depend on IPV6 being statically compiled in as well.
An alternative to the current configuration is to automatically select
IPV6=y in the background when selecting IP_VS_IPV6 (and always showing
IP_VS_IPV6). I remember a thread on lkml about that a long while ago,
but don't know the current Kconfig policies regarding this.
I realize that compile != run, but could you possibly point me in the
direction of _why_ IPVS_IPV6 won't work when built in a modular
fashion? My personal preference for things like ipvs is that they're
built as a module, so that if I do or don't need them, I don't have to
compile+reboot a production machine in order to support new projects.
Additionally, if a module's misbehaving, it's generally pretty easy to
rmmod and insmod, without actually having to take the machine down.
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html