On Fri, 5 Jul 2024 10:06:12 +1000 David Gibson <david(a)gibson.dropbear.id.au> wrote:On Thu, Jul 04, 2024 at 11:21:21PM +0200, Stefano Brivio wrote:Oh, oops, I thought SO_REUSEADDR were specific to Linux, that's why I was suggesting linux/, but it's actually supported by all the BSDs.On Thu, 4 Jul 2024 14:58:34 +1000 David Gibson <david(a)gibson.dropbear.id.au> wrote:Well.. if we ever port to something non-Linux, we'll need the same socket behaviour there. Indeed, that's one reason I think having these test programs is valuable. So I don't think 'linux/' is a great pick.For the approach we intend to use for handling UDP flows, we have some pretty specific requirements about how SO_REUSEADDR works with UDP sockets. Specifically SO_REUSEADDR allows multiple sockets with overlapping bind()s, and therefore there can be multiple sockets which are eligible to receive the same datagram. Which one will actually receive it is important to us. Add a test program which verifies things work the way we expect, which documents what those expectations are in the process. Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> --- contrib/udp-behaviour/.gitignore | 1 + contrib/udp-behaviour/Makefile | 45 ++++ contrib/udp-behaviour/common.c | 66 ++++++ contrib/udp-behaviour/common.h | 47 ++++ contrib/udp-behaviour/reuseaddr-priority.c | 240 +++++++++++++++++++++ 5 files changed, 399 insertions(+)I reviewed these (10/11 and 11/11) a bit lightly, but they look sane to me. I just wonder: wouldn't it be better to have contrib/linux/udp-behaviour instead, so that it's consistent with the other stuff unter contrib/ (project names, kind of)?In some ways contrib/ isn't really the right place for this. Maybe it would be better under doc/? But at the moment that's more user facing than developer facing documentation.I would still say it's documentation and it can happily fit under doc/. Distribution packages don't copy the whole doc/ (to /usr/share/doc/) anyway. Or test/kernel/? But it's not something we want to check regularly, it's really an example to help with development. All in all, I don't have a strong preference, doc/ looks like a better fit to me, but contrib/ isn't problematic either. -- Stefano