From owner-freebsd-pf@FreeBSD.ORG Thu Dec 5 10:47:43 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 4C899A08 for ; Thu, 5 Dec 2013 10:47:43 +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 AD3B010F8 for ; Thu, 5 Dec 2013 10:47:41 +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 rB5AlQGR076627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Dec 2013 14:47:26 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rB5AlQs6076626; Thu, 5 Dec 2013 14:47:26 +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 14:47:26 +0400 From: Gleb Smirnoff To: Kajetan Staszkiewicz Subject: Re: [patch] Source entries removing is awfully slow. Message-ID: <20131205104725.GT48919@glebius.int.ru> References: <201303081419.17743.vegeta@tuxpowered.net> <201312041529.21788.vegeta@tuxpowered.net> <20131205081848.GQ48919@glebius.int.ru> <201312051107.39932.vegeta@tuxpowered.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201312051107.39932.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 10:47:43 -0000 Kajetan, On Thu, Dec 05, 2013 at 11:07:39AM +0100, Kajetan Staszkiewicz wrote: K> > K> To have the most clean and simple code it would make the most sense to K> > use the K> aforementioned pfioc_universal_kill for both DIOCKILLSTATES and K> > K> DIOCKILLSRCNODES. But that would be a change of kernel api which I K> > assume can K> not take place inside major release, so translation of K> > structures is currently K> the way to go. Please correct me if I am wrong. K> > K> > It is okay to add new API. K> K> I was rather thinking about leaving DIOCKILLSTATES and DIOCKILLSRCNODES ioctls K> in place but change the structure passed to them to pfioc_universal_killer. So K> changint the existing API. That can't be merged. K> > So in head we will add new API/ABI, then remove obsoleted one. We will K> > merge only addition to stable/10, not removal. K> > K> > The ABI constraints for stable branches are the following. Newer kernel K> > must work with older utilxities. So, 10.1 kernel will work with pfctl from K> > 10.0, since old ioctls are still supported. K> K> Is recompiling older utilities allowed? Please note that I need to add K> ps(n?)k_table to (pfioc_src_nod|stat)e_kill and psnk_killed_states to K> psnk_src_node_kill anyway. If not, then we must consider that this patch could K> get only into head, and only with struct pfioc_universal_kill. I see no reason K> to clean up the old parser without adding the new syntax with new parameters. Recompiling old utilites is allowed. So, the plan, that would work sounds like that: 1) Add new ioctl number and new structure. Rewrite pfctl to handle it. 2) Remove old ioctls and structures. 3) Merge 1). What we achieve: 10.1 kernel understands 10.1 pfctl ans has new functionality. 10.1 kernel understands 10.0 pfctl. -- Totus tuus, Glebius.