From owner-freebsd-pf@FreeBSD.ORG Thu Dec 5 08:19:07 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E30F0365 for ; Thu, 5 Dec 2013 08:19:07 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4E01116C0 for ; Thu, 5 Dec 2013 08:19:06 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id rB58In97075607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Dec 2013 12:18:49 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rB58Imtx075606; Thu, 5 Dec 2013 12:18:48 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 5 Dec 2013 12:18:48 +0400 From: Gleb Smirnoff To: Kajetan Staszkiewicz Subject: Re: [patch] Source entries removing is awfully slow. Message-ID: <20131205081848.GQ48919@glebius.int.ru> References: <201303081419.17743.vegeta@tuxpowered.net> <201312021728.58010.vegeta@tuxpowered.net> <20131202163927.GM48919@glebius.int.ru> <201312041529.21788.vegeta@tuxpowered.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201312041529.21788.vegeta@tuxpowered.net> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: "freebsd-pf@freebsd.org" X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 08:19:07 -0000 Kajetan, On Wed, Dec 04, 2013 at 03:29:21PM +0100, Kajetan Staszkiewicz wrote: K> Dnia poniedziałek, 2 grudnia 2013 o 17:39:27 Gleb Smirnoff napisał(a): K> K> > I won't object on any interface that is consistent and resides in the K> > '-K' and '-k' namespace. As said before, I am against utilizing new K> > letters for options to avoid clashing with pfctl syntax in OpenBSD. K> K> I have a nice commandline parser working, but I got blocked by one problem. As K> the parser is quite big and most options are common for -K and -k, the parser K> is just one function for both operation modes (and a similar thing for the K> loops going over IP addresses found by given host names). Unfortunately K> DIOCKILLSTATES and DIOCKILLSRCNODES are using separate structures. K> K> Whatever the parser reads, it puts the result in the following structure K> (defined only inside pfctl, not kernel): K> K> struct pfioc_universal_kill { K> sa_family_t puk_af; K> int puk_proto; K> struct pf_rule_addr puk_src; K> struct pf_rule_addr puk_dst; K> struct pf_rule_addr puk_rdr; K> struct pf_state_cmp puk_pfcmp; K> char puk_ifname[IFNAMSIZ]; K> char puk_label[PF_RULE_LABEL_SIZE]; K> char puk_table[PF_TABLE_NAME_SIZE]; K> u_int puk_killed_states; K> u_int puk_killed_src_nodes; K> }; K> K> Which later gets translated for every ioctl to pfioc_src_node_kill or K> pfioc_state_kill. K> K> To have the most clean and simple code it would make the most sense to use the K> aforementioned pfioc_universal_kill for both DIOCKILLSTATES and K> DIOCKILLSRCNODES. But that would be a change of kernel api which I assume can K> not take place inside major release, so translation of structures is currently K> the way to go. Please correct me if I am wrong. It is okay to add new API. So in head we will add new API/ABI, then remove obsoleted one. We will merge only addition to stable/10, not removal. The ABI constraints for stable branches are the following. Newer kernel must work with older utilities. So, 10.1 kernel will work with pfctl from 10.0, since old ioctls are still supported. -- Totus tuus, Glebius.