This relocation is necessary as the backend (osmo_io_fd or
osmo_io_uring) requires a different approach in handling connect
notifications. As a result, a function call has been introduced to
struct iofd_backend_ops.
In a subsequent patch, the process for the osmo_io_uring backend will
be modified to handle SCTP connect notifications using poll/select.
If connect notification is requested using poll/select, the file
descriptior must be registered to osmo_fd, using osmo_fd_register. If
read / write notification is requested by application, the file
descriptior must be registered also. A flag is used prevent calling
osmo_fd_register / osmo_fd_unregister multiple times, which would cause
a crash.
Change-Id: I905ec85210570aff8addadfc9603335d04eb057a
Related: OS#5751
As we introduce more modes, and each mode aliases call-back function
pointers to those of another mode, we have more and more error cases
where we (for exampele) access read_cb, but in reality the user has
populated recvfrom_cb.
Let's use a struct, meaning that call-backs of one mode no longer alias
to the same memory locations of call-backs fro another mode. This
allows us to properly check if the user actually provided the right
callbacks for the given mode of the iofd.
This breaks ABI, but luckily not API. So a simple recompile of
higher-layer library + application code will work.
Change-Id: I9d302df8d00369e7b30437a52deb205f75882be3
The current code does not check the value range of the 'mode' parameter
and would later run into OSMO_ASSERT(), rather than rejecting such a
mode from the very beginning.
Change-Id: I10dd612487638f456d0ad59c2cca203f1e098da3
Related: OS#5751
The two functions of the SCTP socket interface we use in osmo-* are
sctp_send() and sctp_recvmsg(). We do not use sctp_sendmsg() at all,
so let's make sure the mode is named correctly.
Change-Id: Ie2d1c7ce6f211dbe025a0e843ad733443102ea15
Related: OS#5751
Allow the callbacks to be NULL, but then sending/receiving is disabled.
There are some cases where we only care about writing to or reading from
an fd.
Change-Id: I11ce072510b591f7881d09888524426579bd0169
msg was made a parent of msghdr after discussion in change
I3a279b55a3adff96948120683c844e1508d0ba94
It turns out this violates some assumptions made in osmo_io,
specifically that the user read callback shall free msg, but we expect
msghdr to remain valid until after that callback returns.
In general I think it is cleaner to make iofd a parent of msghdr.
Change-Id: I41277190e3020cd8fa625bd57a743973e2a65c4b
Ensure that a msgb has the proper talloc parent:
All msgbs inside an iofd get the iofd as parent. Received msgbs are reparented
to iofd->msgb_alloc.ctx (which was set in osmo_iofd_setup()) before
being passed to the receive callback.
Before this change the code could fail for msgbs that are submitted via uring
where the (failed) write returns after the iofd has already been
osmo_iofd_free()d. free()ing the iofd is deferred until the write
completes, but the (iofd) parent context could have been free()d in the
meantime.
Change-Id: I3a279b55a3adff96948120683c844e1508d0ba94
Use talloc_steal() if a msg is passed in to osmo_io when sending. This
avoids the message being free()d early in case the original parent is
free()d.
Change-Id: Ie36bd68a8bd63e67d76fb41996f8fdf99f51d96c
We need to account for the fact that segmentation_cb() could have
changed the length by calling msgb_pull(). Calculate the new len
according to the new tail/data pointers.
Change-Id: I5486ddc0d3345e92b20cbc6e5bcf2cefea3958c8
This is used for parsing e.g. the ipa header and setting msg->cb.
Guard against segmentation_cb changing msg->data in
iofd_handle_segmentation().
Change-Id: Idd2115baae98a7818aabb26232d4423d2d48fb5c
Don't call write_enable() in osmo_iofd_register(). This was used to
detect whether a socket is connected or not, but would always be
enabled, even on unconnected sockets. Instead make this behaviour
explicit by calling osmo_iofd_notify_connected().
Change-Id: Ieed10bc94c8aad821c0a8f7764db0e05c054c1e3
Enable write on first message in both iofd_txqueue_enqueue{,_front}(),
but only if the iofd is not closed.
Change-Id: I75827491bb9fe0c6d1e4a195ac434f049b1a6ba6
This allows renaming the iofd at any later point in time. This is useful
for instance if the parent object holding the iofd changes its name.
Change-Id: If2772a3ccaa98616e0189862a49ab0243435e343
Rename msg_len -> received_len, len -> expected_len
so the variable names have a consistent scheme.
For instance,
extra_len = msg_len - len
becomes
extra_len = received_len - expected_len
Change-Id: I3d752ce91a1b16c855522f643d10a52ef28a8a84
libosmo-netif does a non blocking connect(), which as per definition of
the socket API is signalled from the OS to the user by marking the file
descriptor writable.
osmo_io needs to signal this somehow. Previously osmo_io would only call
the write_cb if actual data has been sent. This patch changes the behaviour
so that calling osmo_iofd_write_enable() will call write_cb() on a writable
socket even if the write queue is empty.
Change-Id: I893cbc3becd5e125f2f06b3654578aed0aacadf3
The read length is not needed in the segmentation callback, msgb
already has all the necessary information, the parameter previously was
just msgb_length(msg).
Also handle negative return values (except -EAGAIN) of the callback as
errors which cause the msg to be dropped. -EAGAIN will defer the msg.
Change-Id: I6a0eebb8d4490f09a3cc6eb97d4ff47b4a8fd377
Added, because the field 'io_ops' of 'struct osmo_io_fd' is not a
reference, so subsequent changes to the osmo_io_ops structure that was
used to set it up aren't automatically reflected in the osmo_io_fd
structure that got its copy.
Change-Id: Ie45402ad8e86e3cecf75ad78a512c17e61e68b19
* make backend configurable for later
* segmentation callback for chunked streams
* logging target for osmo_io
* support partial writes
Change-Id: I50d73cf550d6ce8154bf827bf47408131cf5b0a0
Related: SYS#5094, OS#5751
Andreas Eversberg
Harald Welte
Daniel Willmann
Pau Espin