Re: svn commit: r272886 - in head/sys: netinet netinet6
On Monday, January 12, 2015 05:42:34 PM Bjoern A. Zeeb 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. I was wondering if it could be used similarly for IPsec UDPencap but I think that went nowhere back then. It is the IPsec UDPencap case I was thinking of. If that is a dead end then the only consumer is already in-tree, so in this case I think this is ok to MFC (but remember to bump __FreeBSD_version). -- John Baldwin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r272886 - in head/sys: netinet netinet6
On Mon, Jan 12, 2015 at 5:20 PM, Michael Tuexen tue...@fh-muenster.de wrote: 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. 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. — 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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r272886 - in head/sys: netinet netinet6
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. -- John Baldwin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r272886 - in head/sys: netinet netinet6
On Mon, Jan 12, 2015 at 9:51 AM, 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. The only in tree consumer is SCTP. -- John Baldwin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r272886 - in head/sys: netinet netinet6
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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r272886 - in head/sys: netinet netinet6
On 1/12/15 11:12 AM, Bryan Venteicher wrote: On Mon, Jan 12, 2015 at 9:51 AM, John Baldwin j...@baldwin.cx mailto: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 mailto: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 mailto: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 mailto: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. 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 ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r272886 - in head/sys: netinet netinet6
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. 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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r272886 - in head/sys: netinet netinet6
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. Phabricator: https://reviews.freebsd.org/D383 Reviewed by: gnn Modified: head/sys/netinet/sctputil.c head/sys/netinet/udp_usrreq.c head/sys/netinet/udp_var.h head/sys/netinet6/udp6_usrreq.c Thanks, JN -- Regards, Bryan Drewery ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r272886 - in head/sys: netinet netinet6
Bryan- On Oct 10, 2014, at 12:09 AM, Bryan Venteicher 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? Phabricator: https://reviews.freebsd.org/D383 Reviewed by: gnn Modified: head/sys/netinet/sctputil.c head/sys/netinet/udp_usrreq.c head/sys/netinet/udp_var.h head/sys/netinet6/udp6_usrreq.c Thanks, JN ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r272886 - in head/sys: netinet netinet6
On Tue, Jan 6, 2015 at 2:52 PM, John Nielsen li...@jnielsen.net wrote: Bryan- On Oct 10, 2014, at 12:09 AM, Bryan Venteicher 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. Phabricator: https://reviews.freebsd.org/D383 Reviewed by: gnn Modified: head/sys/netinet/sctputil.c head/sys/netinet/udp_usrreq.c head/sys/netinet/udp_var.h head/sys/netinet6/udp6_usrreq.c Thanks, JN ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r272886 - in head/sys: netinet netinet6
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. Phabricator: https://reviews.freebsd.org/D383 Reviewed by: gnn Modified: head/sys/netinet/sctputil.c head/sys/netinet/udp_usrreq.c head/sys/netinet/udp_var.h head/sys/netinet6/udp6_usrreq.c Thanks, JN -- Regards, Bryan Drewery ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r272886 - in head/sys: netinet netinet6
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.
Phabricator: https://reviews.freebsd.org/D383
Reviewed by: gnn
Modified:
head/sys/netinet/sctputil.c
head/sys/netinet/udp_usrreq.c
head/sys/netinet/udp_var.h
head/sys/netinet6/udp6_usrreq.c
Modified: head/sys/netinet/sctputil.c
==
--- head/sys/netinet/sctputil.c Fri Oct 10 03:20:12 2014(r272885)
+++ head/sys/netinet/sctputil.c Fri Oct 10 06:08:59 2014(r272886)
@@ -6832,7 +6832,8 @@ sctp_log_trace(uint32_t subsys, const ch
#endif
static void
-sctp_recv_udp_tunneled_packet(struct mbuf *m, int off, struct inpcb *ignored)
+sctp_recv_udp_tunneled_packet(struct mbuf *m, int off, struct inpcb *ignored,
+const struct sockaddr *sa SCTP_UNUSED, void *ctx SCTP_UNUSED)
{
struct ip *iph;
@@ -6968,7 +6969,7 @@ sctp_over_udp_start(void)
}
/* Call the special UDP hook. */
if ((ret = udp_set_kernel_tunneling(SCTP_BASE_INFO(udp4_tun_socket),
- sctp_recv_udp_tunneled_packet))) {
+ sctp_recv_udp_tunneled_packet, NULL))) {
sctp_over_udp_stop();
return (ret);
}
@@ -6992,7 +6993,7 @@ sctp_over_udp_start(void)
}
/* Call the special UDP hook. */
if ((ret = udp_set_kernel_tunneling(SCTP_BASE_INFO(udp6_tun_socket),
- sctp_recv_udp_tunneled_packet))) {
+ sctp_recv_udp_tunneled_packet, NULL))) {
sctp_over_udp_stop();
return (ret);
}
Modified: head/sys/netinet/udp_usrreq.c
==
--- head/sys/netinet/udp_usrreq.c Fri Oct 10 03:20:12 2014
(r272885)
+++ head/sys/netinet/udp_usrreq.c Fri Oct 10 06:08:59 2014
(r272886)
@@ -312,7 +312,8 @@ udp_append(struct inpcb *inp, struct ip
*/
up = intoudpcb(inp);
if (up-u_tun_func != NULL) {
- (*up-u_tun_func)(n, off, inp);
+ (*up-u_tun_func)(n, off, inp, (struct sockaddr *)udp_in,
+ up-u_tun_ctx);
return;
}
@@ -1717,7 +1718,7 @@ udp_attach(struct socket *so, int proto,
#endif /* INET */
int
-udp_set_kernel_tunneling(struct socket *so, udp_tun_func_t f)
+udp_set_kernel_tunneling(struct socket *so, udp_tun_func_t f, void *ctx)
{
struct inpcb *inp;
struct udpcb *up;
@@ -1733,6 +1734,7 @@ udp_set_kernel_tunneling(struct socket *
return (EBUSY);
}
up-u_tun_func = f;
+ up-u_tun_ctx = ctx;
INP_WUNLOCK(inp);
return (0);
}
Modified: head/sys/netinet/udp_var.h
==
--- head/sys/netinet/udp_var.h Fri Oct 10 03:20:12 2014(r272885)
+++ head/sys/netinet/udp_var.h Fri Oct 10 06:08:59 2014(r272886)
@@ -55,7 +55,8 @@ struct udpiphdr {
struct inpcb;
struct mbuf;
-typedef void(*udp_tun_func_t)(struct mbuf *, int off, struct inpcb *);
+typedef void(*udp_tun_func_t)(struct mbuf *, int off, struct inpcb *,
+ const struct sockaddr *, void *);
/*
* UDP control block; one per udp.
@@ -65,6 +66,7 @@ struct udpcb {
u_int u_flags;/* Generic UDP flags. */
uint16_tu_rxcslen; /* Coverage for incoming datagrams. */
uint16_tu_txcslen; /* Coverage for outgoing datagrams. */
+ void*u_tun_ctx; /* Tunneling callback context. */
};
#defineintoudpcb(ip) ((struct udpcb *)(ip)-inp_ppcb)
@@ -176,7 +178,8 @@ voidudplite_input(struct mbuf *, int);
struct inpcb *udp_notify(struct inpcb *inp, int errno);
intudp_shutdown(struct socket *so);
-intudp_set_kernel_tunneling(struct socket *so, udp_tun_func_t f);
+intudp_set_kernel_tunneling(struct socket *so, udp_tun_func_t f,
+void *ctx);
#endif /* _KERNEL */
Modified: head/sys/netinet6/udp6_usrreq.c
==
--- head/sys/netinet6/udp6_usrreq.c Fri Oct 10 03:20:12 2014
(r272885)
+++ head/sys/netinet6/udp6_usrreq.c Fri Oct 10 06:08:59 2014
(r272886)
@@ -150,7 +150,8 @@ udp6_append(struct inpcb *inp, struct mb
*/
up = intoudpcb(inp);
if
