| Message ID | alpine.DEB.2.00.1205101724370.19418@blackhole.kfki.hu |
|---|---|
| State | Not Applicable |
| Headers | show |
Hi, On Thu, May 10, 2012 at 10:27 PM, Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> wrote: > Hi, > > On Thu, 10 May 2012, Neutron Soutmun wrote: > > What about the next much simpler patch to force dependency tracking? > > diff --git a/configure.ac b/configure.ac > index d9a71d3..af8fe0b 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -145,6 +145,9 @@ AM_CONDITIONAL([ENABLE_SHARED], [test > "x$enable_shared" = xyes]) > dnl Checks for programs > : ${CFLAGS=""} > > +dnl Enable dependency tracking unconditionally > +: ${enable_dependency_tracking=yes} > + > AC_PROG_CC > AM_PROG_CC_C_O > AC_PROG_LIBTOOL > > It seems to solve the issue just fine. I think it's too aggressive as some people require this option "--disable-dependency-tracking speeds up one-time build", eg, Debian package build, perhaps Fedora/RedHat rpm build also. BTW, this patch is based on the Makefile.in that auto-generated by autotools, hence, IMO - it's trivial solution. Best regards, Neutron Soutmun -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 10, 2012 at 10:52 PM, Neutron Soutmun <neo.neutron@gmail.com> wrote: > Hi, > > On Thu, May 10, 2012 at 10:27 PM, Jozsef Kadlecsik > <kadlec@blackhole.kfki.hu> wrote: >> Hi, >> >> On Thu, 10 May 2012, Neutron Soutmun wrote: >> >> What about the next much simpler patch to force dependency tracking? >> >> diff --git a/configure.ac b/configure.ac >> index d9a71d3..af8fe0b 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -145,6 +145,9 @@ AM_CONDITIONAL([ENABLE_SHARED], [test >> "x$enable_shared" = xyes]) >> dnl Checks for programs >> : ${CFLAGS=""} >> >> +dnl Enable dependency tracking unconditionally >> +: ${enable_dependency_tracking=yes} >> + >> AC_PROG_CC >> AM_PROG_CC_C_O >> AC_PROG_LIBTOOL >> >> It seems to solve the issue just fine. > > I think it's too aggressive as some people require this option > "--disable-dependency-tracking speeds up one-time build", > eg, Debian package build, perhaps Fedora/RedHat rpm build also. > > BTW, this patch is based on the Makefile.in that auto-generated by > autotools, hence, IMO - it's trivial solution. s/this patch/my proposed patch -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>> No, it's for the userspace tool. The set types can be compiled as dynamic >> modules (shared libraries), instead of statically compiling into the >> "ipset" binary. >> > Got it! I always assumed that the userspace modules got compiled as .so > files, so I must have been looking into the future ;-) . I also assume > that I may configure which modules to include and which to leave out, > right (otherwise I don't see the point of this feature)? the point of this feature is providing the easy way that the third-party or the experimental modules plug into the existing ipset userspace binary without recompile. You could build the experimental ipset "FOO" kernel module and build the shared-lib of "FOO" userspace tool module and plug into the system without recompile the ipset userspace tool at all. It's inspired by iptables (kernel/userspace module). -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> the point of this feature is providing the easy way that the > third-party or the experimental modules > plug into the existing ipset userspace binary without recompile. > > You could build the experimental ipset "FOO" kernel module and build > the shared-lib of "FOO" userspace tool module and > plug into the system without recompile the ipset userspace tool at > all. It's inspired by iptables (kernel/userspace module). > Is there a documentation on how to do that? For example, if I wish to add my own ipset type/matching (as a separate module), where do I start looking? -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 11, 2012 at 5:00 AM, Mr Dash Four <mr.dash.four@googlemail.com> wrote: > >> the point of this feature is providing the easy way that the >> third-party or the experimental modules >> plug into the existing ipset userspace binary without recompile. >> >> You could build the experimental ipset "FOO" kernel module and build >> the shared-lib of "FOO" userspace tool module and >> plug into the system without recompile the ipset userspace tool at >> all. It's inspired by iptables (kernel/userspace module). >> > > Is there a documentation on how to do that? For example, if I wish to add my > own ipset type/matching (as a separate module), where do I start looking? Nothing yet. However I'm working on the "ipset_hash_iplookup" which is proposed to be used with "SETRAWNAT" target. Both are my experimental ipset type and iptables/xtables target respectively. No problems for SETRAWNAT as the iptables/xtables provides the dynamic module loading support already. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 10 May 2012, Mr Dash Four wrote: > > the point of this feature is providing the easy way that the > > third-party or the experimental modules > > plug into the existing ipset userspace binary without recompile. > > > > You could build the experimental ipset "FOO" kernel module and build > > the shared-lib of "FOO" userspace tool module and > > plug into the system without recompile the ipset userspace tool at > > all. It's inspired by iptables (kernel/userspace module). > > > Is there a documentation on how to do that? For example, if I wish to > add my own ipset type/matching (as a separate module), where do I start > looking? As documentation, there's nothing yet. The userspace part of a set type is quite simple: just the parsing, printing, dimension, supported families have to be definied. The kernel part is, well, another matter. Of course all the existing types can be used as examples. Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 11, 2012 at 3:40 PM, Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> wrote: > On Thu, 10 May 2012, Mr Dash Four wrote: > >> > the point of this feature is providing the easy way that the >> > third-party or the experimental modules >> > plug into the existing ipset userspace binary without recompile. >> > >> > You could build the experimental ipset "FOO" kernel module and build >> > the shared-lib of "FOO" userspace tool module and >> > plug into the system without recompile the ipset userspace tool at >> > all. It's inspired by iptables (kernel/userspace module). >> > >> Is there a documentation on how to do that? For example, if I wish to >> add my own ipset type/matching (as a separate module), where do I start >> looking? > > As documentation, there's nothing yet. > > The userspace part of a set type is quite simple: just the > parsing, printing, dimension, supported families have to be definied. > The kernel part is, well, another matter. Of course all the existing > types can be used as examples. I definitely agree with you, all the existing types can be used as examples. /me: $ git clone <ipset> $ git branch experimental/some_ipset_type $ git checkout experimental/some_ipset_type .... $ make [... test ...] -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> However I'm working on the "ipset_hash_iplookup" which is proposed to > be used with "SETRAWNAT" target. > Both are my experimental ipset type and iptables/xtables target > respectively. No problems for SETRAWNAT as the iptables/xtables > provides the dynamic module loading support already. > I don't suppose you are working on ways to include ipset targets in tc by any chance, are you? *hopeful look* -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 11 May 2012, Mr Dash Four wrote: > > However I'm working on the "ipset_hash_iplookup" which is proposed to > > be used with "SETRAWNAT" target. > > Both are my experimental ipset type and iptables/xtables target > > respectively. No problems for SETRAWNAT as the iptables/xtables > > provides the dynamic module loading support already. > > > I don't suppose you are working on ways to include ipset targets in tc > by any chance, are you? *hopeful look* Nothing required, all iptables targets are supported by tc. Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>> I don't suppose you are working on ways to include ipset targets in tc >> by any chance, are you? *hopeful look* >> > > Nothing required, all iptables targets are supported by tc. > I meant ipsets themselves. In other words, instead of: tc filter add dev ifb0 protocol ip parent be:0 prio 10 u32 match ip src 10.1.1.1/24 match ip dst 10.2.1.1/24 match ip protocol 6 ... to have ipset matching on src, destination, protocol etc instead of specifying hard-coded values, like "10.1.1.1/24", "10.2.1.1/24" and "protocol 6" in the above example. To my knowledge, that isn't yet possible or have I missed something? -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday 2012-05-12 00:58, Mr Dash Four wrote: >>> I don't suppose you are working on ways to include ipset targets in tc by any >>> chance, are you? *hopeful look* >>> >> >> Nothing required, all iptables targets are supported by tc. >> > I meant ipsets themselves. In other words, instead of: > > tc filter add dev ifb0 protocol ip parent be:0 prio 10 u32 match ip src > 10.1.1.1/24 match ip dst 10.2.1.1/24 match ip protocol 6 ... > > to have ipset matching on src, destination, protocol etc instead of specifying > hard-coded values, like "10.1.1.1/24", "10.2.1.1/24" and "protocol 6" in the > above example. > > To my knowledge, that isn't yet possible or have I missed something? There's always the nfmark that you can use, of course. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>> I meant ipsets themselves. In other words, instead of: >> >> tc filter add dev ifb0 protocol ip parent be:0 prio 10 u32 match ip src >> 10.1.1.1/24 match ip dst 10.2.1.1/24 match ip protocol 6 ... >> >> to have ipset matching on src, destination, protocol etc instead of specifying >> hard-coded values, like "10.1.1.1/24", "10.2.1.1/24" and "protocol 6" in the >> above example. >> >> To my knowledge, that isn't yet possible or have I missed something? >> > > There's always the nfmark that you can use, of course. > So, it is not supported then - as I thought it won't be. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/configure.ac b/configure.ac index d9a71d3..af8fe0b 100644 --- a/configure.ac +++ b/configure.ac @@ -145,6 +145,9 @@ AM_CONDITIONAL([ENABLE_SHARED], [test "x$enable_shared" = xyes]) dnl Checks for programs : ${CFLAGS=""} +dnl Enable dependency tracking unconditionally +: ${enable_dependency_tracking=yes} + AC_PROG_CC AM_PROG_CC_C_O