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

[Michael Tuexen]

> On 12 Jan 2015, at 18:42, Bjoern A. Zeeb <bz at FreeBSD.org> wrote:
> 
> 
>> On 12 Jan 2015, at 15:51 , John Baldwin <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> 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.
> 
> 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."
> 
> 
>