From: Mr Dash Four <mr.dash.four@googlemail.com>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: Netfilter Core Team <netfilter-devel@vger.kernel.org>,
Pablo Neira Ayuso <pablo@netfilter.org>,
Patrick McHardy <kaber@trash.net>
Subject: Re: [PATCH v2 1/3] iptables: change 'iface' part in hash:net,iface set
Date: Fri, 13 Jul 2012 01:41:44 +0100 [thread overview]
Message-ID: <4FFF6EC8.60300@googlemail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1207112119460.26540@blackhole.kfki.hu>
> A userspace match/target "works" with the corresponding kernel
> match/target only when their revision numbers match. The new revisions are
> our standard way to introduce new features in matches/targets so that it
> won't break anything and work fine in any old-new kernel-iptables
> combinations: the system uses (falls back to) the highest revision which
> is avaliable at both sides.
>
> The new match/target revision in userspace just need the new
> parse/print/save functions, the matching new match/target revision in
> kernel space differ from the current one just in revision number.
>
All noted and tested - that is exactly how it works. Thanks.
>> Similarly, if I rename the new functions to something else, won't that
>> cause compatibility issues where other programs are going to look for
>> these functions (from what I remember these functions are defined in the
>> C header files, so, potentially, after this change they are bound to
>> break something!). Could you elaborate a bit more please?
>>
>
> These functions are static. Nothing else uses them.
>
OK, that's good because I intend to change the parse_dirs function in
the new "version" and introduce additional parameter called "features"
so that these are used directly and not rely on the info->flags to store
these (as was the case up until now). That would also allow for
additional features to be added in the future, if needed (u8 is almost
exhausted - you have one spare bit left there!).
> Let there be long spaces, I'll fix those. But with so long lines, it's
> hard to see the changes.
>
Noted, will do.
> The header files in include/linux/netfilter in the iptables source are
> usually not maintained manually. They are generated from the kernel header
> files by filtering out the kernel specific parts protected by the ifdefs.
>
> At the moment, the enum ip_set_feature definition is kernel specific in
> the kernel header file. Next time Pablo regenerates the header files for
> iptables from the kernel ones, your modification above will be lost.
> Therefore the enum definition must be moved out from the "#ifdef
> __KERNEL__" region in the kernel header file.
>
Yep, just saw that too, so I'll just move the ip_set_feature enum just
above the #ifdef __KERNEL__ part and I assume it would be picked up
"automatically", is that right?
next prev parent reply other threads:[~2012-07-13 0:41 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-09 22:23 [PATCH v2 0/3] iptables: change 'iface' part in hash:net,iface set Mr Dash Four
2012-07-09 22:23 ` [PATCH v2 1/3] " Mr Dash Four
2012-07-10 15:54 ` Jozsef Kadlecsik
2012-07-10 23:41 ` Mr Dash Four
2012-07-12 7:11 ` Jozsef Kadlecsik
2012-07-13 0:41 ` Mr Dash Four [this message]
2012-07-13 8:11 ` Jozsef Kadlecsik
2012-07-13 13:56 ` Mr Dash Four
2012-07-09 22:23 ` [PATCH v2 2/3] ipset: " Mr Dash Four
2012-07-10 15:35 ` Jozsef Kadlecsik
2012-07-09 22:23 ` [PATCH v2 3/3] " Mr Dash Four
2012-07-10 15:32 ` Jozsef Kadlecsik
2012-07-10 23:41 ` Mr Dash Four
2012-07-11 20:25 ` Jozsef Kadlecsik
2012-07-13 0:42 ` Mr Dash Four
2012-07-13 8:02 ` Jozsef Kadlecsik
2012-07-13 13:57 ` Mr Dash Four
2012-07-13 14:16 ` Jozsef Kadlecsik
2012-07-13 14:22 ` Mr Dash Four
2012-07-14 8:45 ` Jozsef Kadlecsik
2012-07-14 12:35 ` Mr Dash Four
2012-07-14 16:37 ` Jozsef Kadlecsik
2012-07-15 11:54 ` Mr Dash Four
2012-07-15 15:02 ` Jozsef Kadlecsik
2012-07-15 16:32 ` Mr Dash Four
2012-07-15 19:21 ` Jozsef Kadlecsik
2012-07-15 19:39 ` Jozsef Kadlecsik
2012-07-15 22:14 ` Mr Dash Four
2012-07-16 8:03 ` Jozsef Kadlecsik
2012-07-16 12:39 ` Mr Dash Four
2012-07-16 13:58 ` Jozsef Kadlecsik
2012-07-17 23:29 ` Mr Dash Four
2012-07-18 12:54 ` Jozsef Kadlecsik
2012-07-19 22:52 ` Mr Dash Four
2012-07-19 22:52 ` Mr Dash Four
2012-07-15 22:48 ` Mr Dash Four
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FFF6EC8.60300@googlemail.com \
--to=mr.dash.four@googlemail.com \
--cc=kaber@trash.net \
--cc=kadlec@blackhole.kfki.hu \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).