From owner-svn-src-head@FreeBSD.ORG Tue Jan 13 18:03:04 2015 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92ACB9D3; Tue, 13 Jan 2015 18:03:04 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 65158315; Tue, 13 Jan 2015 18:03:04 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6C467B93B; Tue, 13 Jan 2015 13:03:02 -0500 (EST) From: John Baldwin To: "Bjoern A. Zeeb" Subject: Re: svn commit: r272886 - in head/sys: netinet netinet6 Date: Mon, 12 Jan 2015 14:54:21 -0500 Message-ID: <9249494.lCU21bPJgC@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <88ADFC71-FD44-4012-9814-1771D31646FF@FreeBSD.org> References: <201410100609.s9A690NU067686@svn.freebsd.org> <6173473.uE5Sr5nj0c@ralph.baldwin.cx> <88ADFC71-FD44-4012-9814-1771D31646FF@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 13 Jan 2015 13:03:02 -0500 (EST) Cc: "src-committers@freebsd.org" , John Nielsen , Bryan Venteicher , "svn-src-all@freebsd.org" , Bryan Drewery , "svn-src-head@freebsd.org" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 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: Tue, 13 Jan 2015 18:03:04 -0000 On Monday, January 12, 2015 05:42:34 PM Bjoern A. Zeeb wrote: > > On 12 Jan 2015, at 15:51 , John Baldwin wrote: > > > > On Tuesday, January 06, 2015 07:07:11 PM Bryan Venteicher wrote: > >> On Tue, Jan 6, 2015 at 5:27 PM, Bryan Drewery wrote: > >>> On 1/6/2015 4:00 PM, Bryan Venteicher wrote: > >>>> On Tue, Jan 6, 2015 at 2:52 PM, John Nielsen >>>> > >>>> > wrote: > >>>> Bryan- > >>>> > >>>> On Oct 10, 2014, at 12:09 AM, Bryan Venteicher >>>>> > >>>> > wrote: > >>>>> Author: bryanv > >>>>> Date: Fri Oct 10 06:08:59 2014 > >>>>> New Revision: 272886 > >>>>> URL: https://svnweb.freebsd.org/changeset/base/272886 > >>>>> > >>>>> Log: > >>>>> Add context pointer and source address to the UDP tunnel callback > >>>>> > >>>>> These are needed for the forthcoming vxlan implementation. The > >>> > >>> context > >>> > >>>>> pointer means we do not have to use a spare pointer field in the > >>> > >>> inpcb, > >>> > >>>>> and the source address is required to populate vxlan's forwarding > >>> > >>> table. > >>> > >>>>> While I highly doubt there is an out of tree consumer of the UDP > >>>>> tunneling callback, this change may be a difficult to eventually > >>> > >>> MFC. > >>> > >>>> I noticed this comment while doing an MFC of vxlan to my local tree. > >>>> Do you think an MFC to 10-STABLE of this change (and vxlan > >>>> generally) will be feasible? Is there precedent for ABI changes like > >>>> this being sanctioned? Could symbol versioning help? > >>>> > >>>> I'd like to get some consensus on whether this commit is OK to MFC. > >>>> With > >>>> this commit, vxlan should be an easy to MFC. > >>> > >>> Breaking ABI will potentially hurt packages. FreeBSD builds packages for > >>> the oldest supported release on a branch. If you break ABI in 10.2 while > >>> we are building packages for 10.1 then any packages using these > >>> interfaces may not work right or result in panics packages with kmods. > >>> Please consider that. > >> > >> The only user visible change of this commit would be the addition of a > >> field at the end of 'struct udpcb'. I don't think that is a problem, at > >> least a similar change didn't prevent the MFC of UDP Lite. > >> > >> The kernel part of this changes the UDP tunneling functions which I guess > >> there could be a 3rd party module out there, but I very highly doubt > >> that, > >> based on how un-useful the previous interface was. > > > > Userland should not be impacted by this at all. (Nothing in userland > > cares > > about udpcb's internals.) I think there was only ever one consumer for > > the > > existing UDP tunneling code (bz@ knows what it is). I'm not sure where it > > lives. > > If you are talking about u_tun_func then it came from SCTP over UDP > tunneling. tuexen and rrs are your friends. > > I was wondering if it could be used similarly for IPsec UDPencap but I think > that went nowhere back then. It is the IPsec UDPencap case I was thinking of. If that is a dead end then the only consumer is already in-tree, so in this case I think this is ok to MFC (but remember to bump __FreeBSD_version). -- John Baldwin