From owner-svn-src-head@FreeBSD.ORG Mon Jan 12 23:20:20 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 72874DB4; Mon, 12 Jan 2015 23:20:20 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 00BB6D98; Mon, 12 Jan 2015 23:20:19 +0000 (UTC) Received: from [192.168.1.200] (p508F271C.dip0.t-ipconnect.de [80.143.39.28]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id BABC71C104DC5; Tue, 13 Jan 2015 00:20:15 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: svn commit: r272886 - in head/sys: netinet netinet6 From: Michael Tuexen In-Reply-To: <88ADFC71-FD44-4012-9814-1771D31646FF@FreeBSD.org> Date: Tue, 13 Jan 2015 00:20:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7A28D39E-7C21-4081-83E0-656F8082D525@fh-muenster.de> References: <201410100609.s9A690NU067686@svn.freebsd.org> <54AC6F4E.1000707@FreeBSD.org> <6173473.uE5Sr5nj0c@ralph.baldwin.cx> <88ADFC71-FD44-4012-9814-1771D31646FF@FreeBSD.org> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.1993) Cc: "src-committers@freebsd.org" , John Nielsen , Bryan Venteicher , "svn-src-all@freebsd.org" , Bryan Drewery , John Baldwin , "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: Mon, 12 Jan 2015 23:20:20 -0000 > On 12 Jan 2015, at 18:42, Bjoern A. Zeeb wrote: >=20 >=20 >> On 12 Jan 2015, at 15:51 , John Baldwin wrote: >>=20 >> 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 >>>>=20 >>>>> > wrote: >>>>> Bryan- >>>>>=20 >>>>> On Oct 10, 2014, at 12:09 AM, Bryan Venteicher = >>>>=20 >>>>> > wrote: >>>>>> Author: bryanv >>>>>> Date: Fri Oct 10 06:08:59 2014 >>>>>> New Revision: 272886 >>>>>> URL: https://svnweb.freebsd.org/changeset/base/272886 >>>>>>=20 >>>>>> Log: >>>>>> Add context pointer and source address to the UDP tunnel callback >>>>>>=20 >>>>>> These are needed for the forthcoming vxlan implementation. The >>>>=20 >>>> context >>>>=20 >>>>>> pointer means we do not have to use a spare pointer field in the >>>>=20 >>>> inpcb, >>>>=20 >>>>>> and the source address is required to populate vxlan's forwarding >>>>=20 >>>> table. >>>>=20 >>>>>> While I highly doubt there is an out of tree consumer of the UDP >>>>>> tunneling callback, this change may be a difficult to eventually >>>>=20 >>>> MFC. >>>>=20 >>>>> 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? >>>>>=20 >>>>> 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. >>>>=20 >>>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>=20 >> 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=20 >> existing UDP tunneling code (bz@ knows what it is). I'm not sure = where it=20 >> lives. >=20 > If you are talking about u_tun_func then it came from SCTP over UDP = tunneling. tuexen and rrs are your friends. rrs implemented it to support SCTP over UDP over IPv[46]. To be more = precisely, to receive such packets. Best regards Michael >=20 > I was wondering if it could be used similarly for IPsec UDPencap but I = think that went nowhere back then. >=20 > =E2=80=94=20 > Bjoern A. Zeeb Charles Haddon = Spurgeon: > "Friendship is one of the sweetest joys of life. Many might have = failed > beneath the bitterness of their trial had they not found a friend." >=20 >=20 >=20