Date: Tue, 13 Jan 2015 09:54:44 -0600 From: Bryan Venteicher <bryanv@freebsd.org> To: Michael Tuexen <tuexen@fh-muenster.de> Cc: "src-committers@freebsd.org" <src-committers@freebsd.org>, John Nielsen <lists@jnielsen.net>, Bryan Venteicher <bryanv@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, Bryan Drewery <bdrewery@freebsd.org>, John Baldwin <john@baldwin.cx>, "Bjoern A. Zeeb" <bz@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r272886 - in head/sys: netinet netinet6 Message-ID: <CAGaYwLd178OUY6CfPfSfDDKBMmpw1iXWKEVsrddL2ZToj0ppiA@mail.gmail.com> In-Reply-To: <7A28D39E-7C21-4081-83E0-656F8082D525@fh-muenster.de> References: <201410100609.s9A690NU067686@svn.freebsd.org> <54AC6F4E.1000707@FreeBSD.org> <CAGaYwLezj6J8AJKFo9wbw3Z-gf8=ip418E%2BvPqr09AZ3f7hsbQ@mail.gmail.com> <6173473.uE5Sr5nj0c@ralph.baldwin.cx> <88ADFC71-FD44-4012-9814-1771D31646FF@FreeBSD.org> <7A28D39E-7C21-4081-83E0-656F8082D525@fh-muenster.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 12, 2015 at 5:20 PM, Michael Tuexen <tuexen@fh-muenster.de> wrote: > > > On 12 Jan 2015, at 18:42, Bjoern A. Zeeb <bz@FreeBSD.org> wrote: > > > > > >> On 12 Jan 2015, at 15:51 , John Baldwin <john@baldwin.cx> wrote: > >> > >> On Tuesday, January 06, 2015 07:07:11 PM Bryan Venteicher wrote: > >>> On Tue, Jan 6, 2015 at 5:27 PM, Bryan Drewery <bdrewery@freebsd.org> > wrote: > >>>> On 1/6/2015 4:00 PM, Bryan Venteicher wrote: > >>>>> On Tue, Jan 6, 2015 at 2:52 PM, John Nielsen <lists@jnielsen.net > >>>>> > >>>>> <mailto:lists@jnielsen.net>> wrote: > >>>>> Bryan- > >>>>> > >>>>> On Oct 10, 2014, at 12:09 AM, Bryan Venteicher <bryanv@freebsd.or= g > >>>>> > >>>>> <mailto:bryanv@freebsd.org>> 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 kmod= s. > >>>> 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 fo= r > 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. > rrs implemented it to support SCTP over UDP over IPv[46]. To be more > precisely, to > receive such packets. > > So I am just being overly cautious and this change is fine to MFC? Best regards > Michael > > > > I was wondering if it could be used similarly for IPsec UDPencap but I > think that went nowhere back then. > > > > =E2=80=94 > > Bjoern A. Zeeb Charles Haddon Spurgeon= : > > "Friendship is one of the sweetest joys of life. Many might have faile= d > > beneath the bitterness of their trial had they not found a friend." > > > > > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGaYwLd178OUY6CfPfSfDDKBMmpw1iXWKEVsrddL2ZToj0ppiA>