On Sat, Sep 17, 2005 at 01:08:58PM +0200, Roman Zippel wrote: > Hi, Hi Roman, thanks for your reply. > On Sat, 17 Sep 2005, Harald Welte wrote: > > > ip_conntrack == CONFIG_IP_NF_CONNTRACK > > nfnetlink == CONFIG_NETFILTER_NETLINK > > ip_conntrack_netlink == CONFIG_IP_NF_CONNTRACK_NETLINK > > > > If nfnetlink == N, ip_conntrack can be N or M or Y > > If nfnetlink == M, ip_conntrack can be N or M > > If nfnetlink == Y, ip_conntrack can be Y or M > > Where is the requirement for the last one coming from? sorry. The last one should be N,M or Y. The fundamental underlying problem is: If CONFIG_IP_NF_CONNTRACK_NETLINK is selected (M or Y), then CONFIG_IP_NF_CONNTRACK conditionally adds some code that references symbols from nfnetlink.ko (CONFIG_NETFILTER_NETLINK) So basically, enabling CONFIG_IP_NF_CONNTRACK_NETLINK creates a dependency from CONFIG_IP_NF_CONNTRACK to CONFIG_NETFILTER_NETLINK. AFAIK, the syntax doesn't allow somthing like tristate IP_NF_CONNTRACK depends on NETFILTER_NETLINK if IP_NF_CONNTRACK_NETLINK!=n So, if ip_conntrack_netlink == M (or Y), and ip_conntrack == Y, then nfnetlink has to be set to Y (but cannot be a module). Is there something that resembles And no, I do not see any chance to solve the problem in the code, without either 1) adding yet another new module that only contains some 1kB of code and that requires additional EXPORT_SYMBOLS() on private data from ip_conntrack or 2) adding dead code to ip_conntrack.ko that isn't used in many common configurations :( -- - Harald Welte <[email protected]> http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie
Attachment:
pgpyc0SqI2rQO.pgp
Description: PGP signature
- Follow-Ups:
- Re: [HELP] netfilter Kconfig dependency nightmare
- From: Roman Zippel <[email protected]>
- Re: [HELP] netfilter Kconfig dependency nightmare
- References:
- [HELP] netfilter Kconfig dependency nightmare
- From: Harald Welte <[email protected]>
- Re: [HELP] netfilter Kconfig dependency nightmare
- From: Roman Zippel <[email protected]>
- [HELP] netfilter Kconfig dependency nightmare
- Prev by Date: Re: I request inclusion of reiser4 in the mainline kernel
- Next by Date: dependance loop on 2.6.14-rc1-mm1
- Previous by thread: Re: [HELP] netfilter Kconfig dependency nightmare
- Next by thread: Re: [HELP] netfilter Kconfig dependency nightmare
- Index(es):