svn commit: r272886 - in head/sys: netinet netinet6

[John Baldwin]

On 1/12/15 11:12 AM, Bryan Venteicher wrote:
>
>
> On Mon, Jan 12, 2015 at 9:51 AM, John Baldwin <john at baldwin.cx
> <mailto:john at 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 at freebsd.org <mailto:bdrewery at 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 at jnielsen.net <mailto:lists at jnielsen.net>
>     > > >
>     > > > <mailto:lists at jnielsen.net <mailto:lists at jnielsen.net>>> wrote:
>     > > >     Bryan-
>     > > >
>     > > >     On Oct 10, 2014, at 12:09 AM, Bryan Venteicher
>     <bryanv at freebsd.org <mailto:bryanv at freebsd.org>
>     > > >
>     > > >     <mailto:bryanv at freebsd.org <mailto:bryanv at 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.
>
>
>
> 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