On Wednesday 2011-04-13 13:08, Ed W wrote: >>> $ cat /tmp/modp.log >>> ip_tables -q >>> -q -- ipt_SET >>> -q -- ipt_SET >>> -q -- ipt_set >>> -q -- ipt_set >> >> The trailing -q is a hint towards the call from iptables, whereas the >> leading -q is kernel-invoked calls. Specifically, it seems that >> xt_set is indeed not built-in, but a module. > >Hmm, that's an interesting point. > >So ipt_SET of course not build in to the kernel (2.6.37/38). Further I >can't find any reference to it in a 2.6.38 kernel tree? I do however see >something in the 2.6.39-rc3 tree (sanity check please - is this correct?) Yes, ipset was first merged into the kernel for 2.6.39. >This would seem to explain why the kernel autoloader was having a try to >find some missing module? It's actually completely missing on this kernel? On your 37/38, yes. >However, I really don't understand the sequence of calls here that has >caused apparently a "modprobe iptables" from xtables.c to trigger the >kernel (?) to try and insert some module that it knows nothing about >(only iptables seems to know about it)? You mentioned your program _is_ actually compiled with --enable-static, as such this applies: Since libxt_SET and libxt_set are built into iptables-multi, their revision will be checked unconditionally (previous to Maciej's patches). Since the 37s and 38s kernel has no xt_SET/set, it will try probing. All looks normal. Including that your modprobe count still is just 5 and not 20+. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
