Patchwork [ANNOUNCE] ipset 6.12 released

login
register
mail settings
Submitter Jozsef Kadlecsik
Date May 10, 2012, 3:27 p.m.
Message ID <alpine.DEB.2.00.1205101724370.19418@blackhole.kfki.hu>
Download mbox | patch
Permalink /patch/158332/
State Not Applicable
Headers show

Comments

Jozsef Kadlecsik - May 10, 2012, 3:27 p.m.
Hi,

On Thu, 10 May 2012, Neutron Soutmun wrote:

> > However, I'll find the solution for the build system when the
> > --disable-dependency-tracking is being parse.
> 
> The attached file is a patch to solve the
> --disable-dependency-tracking is being parse issue and also fixes the
> ipset does not build out of the source tree as the configure script
> could not check for the lib/ipset_*.c.

What about the next much simpler patch to force dependency tracking?

 AC_PROG_LIBTOOL

It seems to solve the issue just fine.

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
Neutron Soutmun - May 10, 2012, 3:52 p.m.
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
Neutron Soutmun - May 10, 2012, 4 p.m.
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
Neutron Soutmun - May 10, 2012, 4:28 p.m.
>> 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
Mr Dash Four - May 10, 2012, 10 p.m.
> 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
Neutron Soutmun - May 11, 2012, 2:37 a.m.
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
Jozsef Kadlecsik - May 11, 2012, 8:40 a.m.
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
Neutron Soutmun - May 11, 2012, 9 a.m.
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
Mr Dash Four - May 11, 2012, 12:45 p.m.
> 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
Jozsef Kadlecsik - May 11, 2012, 7:40 p.m.
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
Mr Dash Four - May 11, 2012, 10:58 p.m.
>> 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
Jan Engelhardt - May 11, 2012, 11:06 p.m.
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
Mr Dash Four - May 11, 2012, 11:20 p.m.
>> 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

Patch

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