> On 12 Jan 2015, at 18:42, Bjoern A. Zeeb <b...@freebsd.org> wrote: > > >> On 12 Jan 2015, at 15:51 , John Baldwin <j...@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 <bdrew...@freebsd.org> wrote: >>>> On 1/6/2015 4:00 PM, Bryan Venteicher wrote: >>>>> On Tue, Jan 6, 2015 at 2:52 PM, John Nielsen <li...@jnielsen.net >>>>> >>>>> <mailto:li...@jnielsen.net>> wrote: >>>>> Bryan- >>>>> >>>>> On Oct 10, 2014, at 12:09 AM, Bryan Venteicher <bry...@freebsd.org >>>>> >>>>> <mailto:bry...@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 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. rrs implemented it to support SCTP over UDP over IPv[46]. To be more precisely, to receive such packets.
Best regards Michael > > I was wondering if it could be used similarly for IPsec UDPencap but I think > that went nowhere back then. > > — > 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." > > > _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
