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

[John Baldwin]

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> 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>> wrote:
> > >     Bryan-
> > >     
> > >     On Oct 10, 2014, at 12:09 AM, Bryan Venteicher <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.

-- 
John Baldwin