This makes a couple of simple re-arrangements in lwip_selscan() that
should improve performance in the following ways:
1) The old code linearly walked all sockets to maxfd regardless of
whether they were set in the fd set. The process involved
acquiring sys arch protect, looking up the socket, and then
checking if the socket was present in any of the fd sets. On
systems with lots of sockets and a heavy SYS_ARCH_PROTECT
infrastructure (a mutex) this can result in a lot of extra work.
Now we skip this process for any fd that is not in the input sets
2) If the socket from tryget_socket() is NULL we no longer continue
and compare the input fd sets with a zeroed out set of events
3) We no longer need to zero out our event sets because they are
only accessed when tryget_socket() is successful
lwip_selscan() is called at most once per select call and sometimes up to three times
This fixes a bug in close when LWIP_SO_SNDTIMEO is enabled, but
the option is not in use on the socket
A simple mis-typed comparison against zero would cause the close_timeout
to get set to zero if conn->send_timeout was 0
The intended check was to over-ride the default close timeout if a
send timeout had been specified via SO_SNDTIMEO
tcpip_callback_with_block() can fail with ERR_MEM or ERR_VAL, and in the
error paths the code does not post the msg to the mailbox thus the
sys_sem_wait() call might wait forever. Fix it by testing return value of
tcpip_callback() and return error immediately.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
The TCPIP_APIMSG_ACK will call NETCONN_SET_SAFE_ERR for both
LWIP_TCPIP_CORE_LOCKING and !LWIP_TCPIP_CORE_LOCKING cases.
So remove superfluous NETCONN_SET_SAFE_ERR call before TCPIP_APIMSG_ACK.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Adds sendmsg implementation for TCP and UDP sockets. Control messages
are not supported at this point, but could be added in the future
https://savannah.nongnu.org/bugs/?44805
Change-Id: Iddb287fd4b693f7563f8c923f76785cdde782d2f
The overall lwIP design on data flows (netif,udp,tcp) is to use a user
defined callback to get data from stack and a static function to send
data to stack, which makes perfect sense. The SIO port was an exception,
the PPP stack never really used the SIO port by only using the
sio_send() function (and the ignominious sio_read_abort() function a
while back).
The way the SIO port is currently designed adds a tight coupling between
the lwIP port and the user code if the user need to do specific user
code if the current uart used is the PPPoS uart, which is not nice,
especially because all the lwIP stack is quite clean at this subject.
While we are at stabilizing the PPP API, change this behavior before
it's too late by replacing the static sio_write() calls to a user
defined callback.
This commit address two issues with sockaddr struct implementations for
IPv6:
1) struct sockaddr_in6 should have 32-bit unsigned field sin6_scope_id
as specified in Section 3.4 of RFC 3493 (Basic Socket Interface
Extensions for IPv6)
2) struct sockaddr is not extended in IPv6 to contain space for
struct sockaddr_in6. Applications should be using struct
sockaddr_storage when needing generic storage. This removes the
extra bytes added when LWIP_IPV6 is defined
