From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pablo Neira Ayuso Subject: Re: [PATCH]: Keep the "state" match as alias [Re: state match is obsolete 1.4.17] Date: Wed, 23 Jan 2013 04:03:41 +0100 Message-ID: <20130123030341.GA2844@1984> References: <50F5273F.5020205@inliniac.net> <20130118002818.GA19003@1984> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Engelhardt , Victor Julien , Nick Edwards , netfilter@vger.kernel.org, netfilter-devel@vger.kernel.org To: Jozsef Kadlecsik Return-path: Received: from mail.us.es ([193.147.175.20]:45289 "EHLO mail.us.es" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752136Ab3AWDDt (ORCPT ); Tue, 22 Jan 2013 22:03:49 -0500 Content-Disposition: inline In-Reply-To: Sender: netfilter-devel-owner@vger.kernel.org List-ID: Hi Jozsef, On Tue, Jan 22, 2013 at 10:47:35PM +0100, Jozsef Kadlecsik wrote: > 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? I remember that, while discussing nfacct, some people mentioned that they were using scripts to parse iptables -L -n to digest counters. I have also found some perl extension [1] that parses `iptables -L -n' output. [1] http://search.cpan.org/dist/IPTables-Parse/