From owner-svn-src-head@FreeBSD.ORG Thu Apr 9 13:56:23 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D52A5106566B; Thu, 9 Apr 2009 13:56:23 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 904D98FC14; Thu, 9 Apr 2009 13:56:23 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 5511273098; Thu, 9 Apr 2009 16:01:29 +0200 (CEST) Date: Thu, 9 Apr 2009 16:01:29 +0200 From: Luigi Rizzo To: Robert Watson Message-ID: <20090409140129.GA58389@onelab2.iet.unipi.it> References: <200904091246.n39Ck05i004627@svn.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: svn-src-head@freebsd.org, Luigi Rizzo , src-committers@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r190865 - in head: sbin/ipfw sys/netinet X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 13:56:24 -0000 On Thu, Apr 09, 2009 at 02:25:59PM +0100, Robert Watson wrote: > On Thu, 9 Apr 2009, Luigi Rizzo wrote: > > > Note- this commit changes the userland/kernel ABI for pipes > > (but not for ordinary firewall rules) so you need to rebuild > > kernel and /sbin/ipfw to use dummynet features. > > > > Please check the manpage for details on the new feature. > > > > The MFC would be trivial but it breaks the ABI, so it will > > be postponed until after 7.2 is released. > > Under our more strict but relatively undocumented -STABLE ABI rules, this > sort of change is no longer permitted. Is there really no way to do this > without breaking the ABI for the purposes of making it more gently MFCable? There is always a way, and it is to provide, within the kernel, some translation glue so that requests issued in "ancient greek" (i.e. the old ABI) will still be accepted and answered properly. while at the same time provide a new ABI that supports the new functionalities. This is what will be done eventually. For now, it is not my intention to do the MFC of _this_ version of the code, it was more a comment for people who asked me this feature on RELENG_7. Unfortunately the "struct dn_pipe" and "struct dn_flow_queue" are not particularly well designed for extensibility (my fault, but it was 10 years ago). Also note that the version in RELENG_7 will definitely need an update because some numeric fields are 32-bit and in this age of Gbit/s links and GHz CPUs are in constant danger of overflow (with the code going to great lengths to minimize the problems). The planned course of action before the MFC is: + add a version/len field to the structure(s) to improve ABI compatibility, as it was done in 2002 for ipfw; + separate the kernel-only information from the one visible to userland, so the ABI problems will be less likely to appear again; Once this is done and stabilized, I will try to do an MFC that, among other things, will use a new sockopt for the new ABI, and include the translation glue for the old ABI. cheers luigi