Hi Ernest,
On 08/18/2017 10:30 PM, Williams Jr., Ernest L. wrote:
> I am experiencing the same issue with EPICS R3.15.5 and RTEMS version "4.9.4"
>
> Can you add the patch to the KnownProblems page?
> http://www.aps.anl.gov/epics/base/R3-15/5-docs/KnownProblems.html
We haven't agreed what the right fix should be yet — Heinz, presumably
your change is included in your RTEMS-4.12 branch?
I would be more inclined to add another typedef to the osdSock.h API for
this data type instead of adding more OS-specific #ifdefs into the
source. There are 2 places in Base-3.15 that make this call:
if (setsockopt(..., IPPROTO_IP, IP_MULTICAST_LOOP,
(char *) &flag, sizeof(flag)) ...
Declaring the flag variable as say
osiSockOptMcastLoop_t flag = 1;
would seem to be a cleaner solution, and in line with how other OS
socket API differences have been resolved in the past.
Any objections to implementing this in Base-3.15?
- Andrew
> From:
[email protected] [
[email protected]] on behalf of Andrew Johnson [
[email protected]]
> Sent: Thursday, April 20, 2017 9:21 AM
> To: Michael Davidsaver; Heinz Junkes;
[email protected]
> Subject: Re: RTEMS: rsrv: failed to set mcast loopback in src/ioc/rsrv/caservertask.c
>
> On 04/20/2017 10:19 AM, Michael Davidsaver wrote:
>> I see that linux (circa 3.16) will accept either 'int' or 'char' for
>> IP_MULTICAST_LOOP. Also for most other integer flags.
>>
>> I find references which suggest that winsock wants BOOL (which I assume
>> is 'char').
>>
>> However, vxworks 5.5 clearly spec's 'int'.
>>
>> http://www.vxdev.com/docs/vx55man/vxworks/ref/sockLib.html
>
> But as long as we're talking about Base-3.16 we don't have to support
> VxWorks 5.5 at all. Wind River completely replaced the network stack in
> VxWorks 6.x, and the newer stack looks like it will support either int
> or char (there's code in setsockopt() for IP_MULTICAST_LOOP which
> appears to handle both sizes, although they haven't updated the docs to
> actually say that).
>
>> Seems like the IP_MULTI* socket options need unit-test coverage. (maybe
>> add to blockingSocketTest.cpp ?)
>
> Agreed, and that seems like the right place for it.
>
> - Andrew
>
> --
> Arguing for surveillance because you have nothing to hide is no
> different than making the claim, "I don't care about freedom of
> speech because I have nothing to say." -- Edward Snowdon
>
--
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon