passt/doc/platform-requirements
David Gibson 01e5611ec3 doc: Test behaviour of closing duplicate UDP sockets
To simplify lifetime management of "listening" UDP sockets, UDP flow
support needs to duplicate existing bound sockets.  Those duplicates will
be close()d when their corresponding flow expires, but we expect the
original to still receive datagrams as always.  That is, we expect the
close() on the duplicate to remove the duplicated fd, but not to close the
underlying UDP socket.

Add a test program to doc/platform-requirements to verify this requirement.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2024-07-17 15:30:14 +02:00
..
.gitignore doc: Test behaviour of closing duplicate UDP sockets 2024-07-17 15:30:14 +02:00
common.c doc: Add program to document and test assumptions about SO_REUSEADDR 2024-07-05 15:26:43 +02:00
common.h doc: Add program to document and test assumptions about SO_REUSEADDR 2024-07-05 15:26:43 +02:00
Makefile doc: Test behaviour of closing duplicate UDP sockets 2024-07-17 15:30:14 +02:00
README doc: Add program to document and test assumptions about SO_REUSEADDR 2024-07-05 15:26:43 +02:00
recv-zero.c doc: Test behaviour of zero length datagram recv()s 2024-07-05 15:26:48 +02:00
reuseaddr-priority.c doc: Trivial fix for reuseaddr-priority 2024-07-15 17:55:52 +02:00
udp-close-dup.c doc: Test behaviour of closing duplicate UDP sockets 2024-07-17 15:30:14 +02:00

Platform Requirements
=====================

TODO: document the various Linux specific features we currently require


Test Programs
-------------

In some places we rely on quite specific behaviour of sockets.
Although Linux, at least, seems to behave as required, It's not always
clear from the available documentation if this is required by POSIX or
some other specification.

To specifically document those expectations this directory has some
test programs which explicitly check for the behaviour we need.
When/if we attempt a port to a new platform, running these to check
behaviour would be a good place to start.