Re: [PATCH]: Keep the "state" match as alias [Re: state match is obsolete 1.4.17]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 18 Jan 2013, Pablo Neira Ayuso wrote:

> On Tue, Jan 15, 2013 at 06:28:11PM +0100, Jozsef Kadlecsik wrote:
> > On Tue, 15 Jan 2013, Jozsef Kadlecsik wrote:
> > 
> > > With passing one more internal flag, indicating that the "state" alias is 
> > > used, the "conntrack" module can remain completely hidden and the user can 
> > > list/save exactly the same command as the issued one.
> > 
> > Here follows the patch which introduces match module aliases (the same can 
> > be done for targets as well). The alias is handled as it were a real 
> > extension while it's actually handled by another module. Listing/saving 
> > keeps the alias name and options.
> > 
> > The "state" extension is the first example of such an alias.
> 
> I like this symmetrical aliasing approach.
> 
> The aim is to get rid of redundant things in the kernel. And with
> this, we can get that without disturbing users.
> 
> Would you do the same for the NOTRACK target?

Yes, but looking through the modules, I see a lot of inconsistencies: in 
listing match names capitalized, some match/target doesn't print its name, 
missing whitespaces, etc.

I'm going to fix those, but quite a lot of simplification could be 
achieved if the options at listing and saving could be generated by the 
same function in a match/target. Like instead of

	ttl match TTL == xxx

I propose to list the match as

	ttl eq xxx

(That is generate listings by striping off the dashes and the match/target 
name prefix from the options.)

The question is: do we have a "stable API" in listings, at this level?

Best regards,
Jozsef
-
E-mail  : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx
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" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux