RTNet and setsockopt
jan.kiszka at siemens.com
Fri Apr 17 08:18:32 CEST 2020
On 16.04.20 20:04, Per Oberg via Xenomai wrote:
> ----- Den 16 apr 2020, på kl 19:00, xenomai xenomai at xenomai.org skrev:
>> ----- Den 16 apr 2020, på kl 18:32, Lange Norbert norbert.lange at andritz.com
>>> Hello Per,
>>> setsockopt is supported by rtnet (and wrapped with the POSIX skin). That said,
>>> it supports very little options you are used from Linux. Do a grep -r on
>>> xenomais sources.
>>> Xenomai mostly uses ioctls for bringing up Interfaces, etc.
>>> There are subtile differences and limitations aswell. I am pretty sure now that
>>> most operations
>>> are behaving like you have an nonblocking filedescriptor / socket. The RT focus
>>> means that there
>>> typically is just a check if buffers are available, and no effort is made for
>>> So select will be your best friend.
>>> (I am just using packet sockets, but I believe it’s the same for all of them).
>> Thanks, I readded the list again. The reason I started looking into this is that
>> I had issues with blocking sends. I wanted to see what happened if I pulled the
>> plug on the ethernet and tried to recover afterwards.
>> Digging around a bit is seems like I might actually have a compiler flag issue
>> (again...). I tried compiling my network code as a shared library.
> Progress, i guess. It was the read that was became non blocking.
> Still: I believe that "setsockopt" is missing for PF_PACKET, SOCK_RAW. I can se that it is implemented for some of the packet types but there is no reference to it in af_packet.c.
> That said, I don't see how setsockopt is mapped to the different variants. I can se how recv and recfrom is mapped using the structure with the ".recvfrom = xxx" syntax but setsockopt seems to be different.
> Also, when looking in the code i see that "MSG_DONTWAIT" is supported for rt_packet_recvmsg and that it sets sock->timeout to -1. So it seems a small fix to make this work, if I only knew where how setsockopt was mapped..
There is RTNET_RTIOC_TIMEOUT to set the timeout of blocked operations on
the socket. I honestly do not recall right now what the reasoning for
going separate was, but adding SO_RCVTIMEO compatibility would sure be
Note that RT-TCP already supports SO_SNDTIMEO.
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
More information about the Xenomai