From owner-svn-src-head@FreeBSD.ORG Mon Jan 12 16:21:22 2015 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E318E349; Mon, 12 Jan 2015 16:21:21 +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 9C4D6212; Mon, 12 Jan 2015 16:21:21 +0000 (UTC) Received: from new-host-4.home (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2AF70B915; Mon, 12 Jan 2015 11:21:19 -0500 (EST) Message-ID: <54B3F47E.5050206@baldwin.cx> Date: Mon, 12 Jan 2015 11:21:18 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Bryan Venteicher Subject: Re: svn commit: r272886 - in head/sys: netinet netinet6 References: <201410100609.s9A690NU067686@svn.freebsd.org> <54AC6F4E.1000707@FreeBSD.org> <6173473.uE5Sr5nj0c@ralph.baldwin.cx> In-Reply-To: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 12 Jan 2015 11:21:19 -0500 (EST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" , John Nielsen , Bryan Drewery 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: Mon, 12 Jan 2015 16:21:22 -0000 On 1/12/15 11:12 AM, Bryan Venteicher wrote: > > > On Mon, Jan 12, 2015 at 9:51 AM, 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. > > > > The only in tree consumer is SCTP. I thought there was some IPSEC use-case that was the original impetus for bz@ adding this? Bjoern really is the person to ask about that though. -- John Baldwin