rtnet-developers

[RTnet-developers] Multicast patch

[Bruno C. <b.c...@ip...>]

Hi,

you can find herejoined an uptodate patch for multicast support working 
with current revision 1155.
Please feel free to comment. The patch is based upon the old amine one.

I'm still working on it and testing it ...

Bruno.

[RTnet-developers] Multicast patch

[Bruno C. <b.c...@ip...>]

Hi all,

i'm sending you an up to date multicast patch, but not the final one 
(i'm not still happy with everything yet ...!)
I've tested it but it could remain bugs ...

Bruno.

Re: [RTnet-developers] Multicast patch

[Gilles C. <gil...@gm...>]

On Tue, Apr 22, 2008 at 6:06 PM, Bruno Carlus <b.c...@ip...> wrote:
> Hi all,
>
>  i'm sending you an up to date multicast patch, but not the final one (i'm
> not still happy with everything yet ...!)
>  I've tested it but it could remain bugs ...

I see many:

if (!(rtdev->flags & IFF_LOOPBACK) && (rtdev->flags & IFF_MULTICAST))

why not:

if (rtdev->flags & (IFF_LOOPBACK | IFF_MULTICAST) == IFF_MULTICAST)

?


-- 
 Gilles

Re: [RTnet-developers] Multicast patch

[Jan K. <jan...@we...>]

Bruno Carlus wrote:
> Hi,
> 
> you can find herejoined an uptodate patch for multicast support working 
> with current revision 1155.

Thanks for re-animating this work!

> Please feel free to comment. The patch is based upon the old amine one.
> 
> I'm still working on it and testing it ...

And therefore only a few general, more or less nitpicking comments:
  - svn-add new files locally before generating the diff
    (igmp.c is missing)
  - Try to keep #ifdef'ery low where possible. E.g., the compiler
    can optimize out "if (some_expression)" if some_expression evaluatues
    to 0 during compile-time. Also, no need for #ifdef'ing prototypes.
  - Try to keep the (granted, non-standard) coding style of RTnet
    consistent

Jan

Re: [RTnet-developers] Multicast patch

[Bruno C. <b.c...@ip...>]

Hi,

to test my multicast patch I tried the following piece of code, simplier 
than the ptp soft, to validate the modifications.
The problem is that the packets are correctly sent and seemed to be 
received by the rtnet udp layer at the other side, but never get to the 
socket layer receiving ...

Other thing maybe in touch when ^c the little program rtdm complains: 
"closing device in real-time mode while creation ran in non real time - 
this is not supported! " maybe related to my problem.

something i did not understand about the xenomai/rtnet posix wrap?

Bruno.

Re: [RTnet-developers] Multicast patch

[Jan K. <jan...@we...>]

Bruno Carlus wrote:
> Hi,
> 
> to test my multicast patch I tried the following piece of code, simplier 
> than the ptp soft, to validate the modifications.
> The problem is that the packets are correctly sent and seemed to be 
> received by the rtnet udp layer at the other side, but never get to the 
> socket layer receiving ...

You can
  - instrument the receiver side to find out what is happening (printk)
  - use some tracer (i-pipe tracer or lttng)
  - run the whole thing under qemu

I recently did the latter before releasing 0.9.10-rc2. Works nicely 
these days as qemu now provides several of the network adapters that 
RTnet supports. Of course, timing is not reliable, BUT... you can debug 
the targets without any kernel patch or additional hardware support! And 
if something crashes, you don't have to leave your seat and walk to some 
reset switch. ;)

> 
> Other thing maybe in touch when ^c the little program rtdm complains: 
> "closing device in real-time mode while creation ran in non real time - 
> this is not supported! " maybe related to my problem.
> 
> something i did not understand about the xenomai/rtnet posix wrap?

Your problem is sock_lock. It forces shutalldown into primary (=RT) mode 
before invoking close(). That neither makes sense nor works if socket() 
was invoked in secondary (=Non-RT) mode. Just gid rid of it.

Jan

Re: [RTnet-developers] Multicast patch

[Bruno C. <b.c...@ip...>]

Jan Kiszka a écrit :
> Bruno Carlus wrote:
>> Hi,
>>
>> to test my multicast patch I tried the following piece of code, 
>> simplier than the ptp soft, to validate the modifications.
>> The problem is that the packets are correctly sent and seemed to be 
>> received by the rtnet udp layer at the other side, but never get to 
>> the socket layer receiving ...
>
> You can
>  - instrument the receiver side to find out what is happening (printk)
>  - use some tracer (i-pipe tracer or lttng)
>  - run the whole thing under qemu
>
> I recently did the latter before releasing 0.9.10-rc2. Works nicely 
> these days as qemu now provides several of the network adapters that 
> RTnet supports. Of course, timing is not reliable, BUT... you can 
> debug the targets without any kernel patch or additional hardware 
> support! And if something crashes, you don't have to leave your seat 
> and walk to some reset switch. ;)
>
my first analysis shows that everything works fine reception-side till 
the rtnet udp layer: the socket coresponding to the multicast @ is found 
by rt_udp_v4_lookup function. But I don't know what happens afterwards 
or where to put trace or debug printouts...

By the way, a version of the code compiled without wrapping with 
xenomai/posix works fine...
>>
>> Other thing maybe in touch when ^c the little program rtdm complains: 
>> "closing device in real-time mode while creation ran in non real time 
>> - this is not supported! " maybe related to my problem.
>>
>> something i did not understand about the xenomai/rtnet posix wrap?
>
> Your problem is sock_lock. It forces shutalldown into primary (=RT) 
> mode before invoking close(). That neither makes sense nor works if 
> socket() was invoked in secondary (=Non-RT) mode. Just gid rid of it.
>
I don't understantd something here, because I thought everything was RT 
since I was compiling with the xeno-config posix flags ...
Does sock_lock also force sendto to run in RT ?
> Jan
>

Thanks,
Bruno.

Re: [RTnet-developers] Multicast patch

[Bruno C. <b.c...@ip...>]

Bruno Carlus a écrit :
> Jan Kiszka a écrit :
>> Bruno Carlus wrote:
>>> Hi,
>>>
>>> to test my multicast patch I tried the following piece of code, 
>>> simplier than the ptp soft, to validate the modifications.
>>> The problem is that the packets are correctly sent and seemed to be 
>>> received by the rtnet udp layer at the other side, but never get to 
>>> the socket layer receiving ...
>>
>> You can
>>  - instrument the receiver side to find out what is happening (printk)
>>  - use some tracer (i-pipe tracer or lttng)
>>  - run the whole thing under qemu
>>
>> I recently did the latter before releasing 0.9.10-rc2. Works nicely 
>> these days as qemu now provides several of the network adapters that 
>> RTnet supports. Of course, timing is not reliable, BUT... you can 
>> debug the targets without any kernel patch or additional hardware 
>> support! And if something crashes, you don't have to leave your seat 
>> and walk to some reset switch. ;)
>>
> my first analysis shows that everything works fine reception-side till 
> the rtnet udp layer: the socket coresponding to the multicast @ is 
> found by rt_udp_v4_lookup function. But I don't know what happens 
> afterwards or where to put trace or debug printouts...
>
> By the way, a version of the code compiled without wrapping with 
> xenomai/posix works fine...
>>>
>>> Other thing maybe in touch when ^c the little program rtdm 
>>> complains: "closing device in real-time mode while creation ran in 
>>> non real time - this is not supported! " maybe related to my problem.
>>>
>>> something i did not understand about the xenomai/rtnet posix wrap?
>>
>> Your problem is sock_lock. It forces shutalldown into primary (=RT) 
>> mode before invoking close(). That neither makes sense nor works if 
>> socket() was invoked in secondary (=Non-RT) mode. Just gid rid of it.
>>
> I don't understantd something here, because I thought everything was 
> RT since I was compiling with the xeno-config posix flags ...
> Does sock_lock also force sendto to run in RT ?
>> Jan
>>
>
> Thanks,
> Bruno.
>
I just found out the problem, my both points above were actually linked: 
as the sockets weren't closing properly, a binding was still existing 
for rtnet; so when receiving the packets it was picking the first good 
binding in the list and relaying them to this old rt_sock, which wasn't 
linked to anything anymore "above"...
I restarted everything properly (got rid of sock_lock...) and it is 
working with the first opened socket !

Anyway, if anyone (Jan ? ;-) )  could answer my last mail questions 
about RT/non RT it would still help ... !

Bruno.

Re: [RTnet-developers] Multicast patch

[Jan K. <jan...@we...>]

Bruno Carlus wrote:
> Bruno Carlus a écrit :
>> Jan Kiszka a écrit :
>>> Bruno Carlus wrote:
>>>> Hi,
>>>>
>>>> to test my multicast patch I tried the following piece of code, 
>>>> simplier than the ptp soft, to validate the modifications.
>>>> The problem is that the packets are correctly sent and seemed to be 
>>>> received by the rtnet udp layer at the other side, but never get to 
>>>> the socket layer receiving ...
>>>
>>> You can
>>>  - instrument the receiver side to find out what is happening (printk)
>>>  - use some tracer (i-pipe tracer or lttng)
>>>  - run the whole thing under qemu
>>>
>>> I recently did the latter before releasing 0.9.10-rc2. Works nicely 
>>> these days as qemu now provides several of the network adapters that 
>>> RTnet supports. Of course, timing is not reliable, BUT... you can 
>>> debug the targets without any kernel patch or additional hardware 
>>> support! And if something crashes, you don't have to leave your seat 
>>> and walk to some reset switch. ;)
>>>
>> my first analysis shows that everything works fine reception-side till 
>> the rtnet udp layer: the socket coresponding to the multicast @ is 
>> found by rt_udp_v4_lookup function. But I don't know what happens 
>> afterwards or where to put trace or debug printouts...
>>
>> By the way, a version of the code compiled without wrapping with 
>> xenomai/posix works fine...
>>>>
>>>> Other thing maybe in touch when ^c the little program rtdm 
>>>> complains: "closing device in real-time mode while creation ran in 
>>>> non real time - this is not supported! " maybe related to my problem.
>>>>
>>>> something i did not understand about the xenomai/rtnet posix wrap?
>>>
>>> Your problem is sock_lock. It forces shutalldown into primary (=RT) 
>>> mode before invoking close(). That neither makes sense nor works if 
>>> socket() was invoked in secondary (=Non-RT) mode. Just gid rid of it.
>>>
>> I don't understantd something here, because I thought everything was 
>> RT since I was compiling with the xeno-config posix flags ...
>> Does sock_lock also force sendto to run in RT ?
>>> Jan
>>>
>>
>> Thanks,
>> Bruno.
>>
> I just found out the problem, my both points above were actually linked: 
> as the sockets weren't closing properly, a binding was still existing 
> for rtnet; so when receiving the packets it was picking the first good 
> binding in the list and relaying them to this old rt_sock, which wasn't 
> linked to anything anymore "above"...
> I restarted everything properly (got rid of sock_lock...) and it is 
> working with the first opened socket !

Nice to hear.

> 
> Anyway, if anyone (Jan ? ;-) )  could answer my last mail questions 
> about RT/non RT it would still help ... !

Sendto itself will force the caller into primary mode (if it wasn't 
already) if and only if the socket it operates on is provided by RTnet.

Under the Xenomai POSIX skin, this is the case if you invoke socket() 
with a RTnet-support protocol. Unsupported protocols (e.g. TCP) or 
__real_socket() invocation will be passed down to Linux and succeeding 
sendto (or other sevices) on the related file descriptor will also be 
handled.

Hope that helped to clarify the mechanism.

Jan

[RTnet-developers] Linux socket close/unbind mechanisms

[Bruno C. <b.c...@ip...>]

Hi all,

Does anyone know wether it exixts under linux, a mechanism that 
automatically unbinds and closes a socket not properly released by its 
parent process ? Could it be apply to RTnet udp socket ?

Thanks,
Bruno.

Re: [RTnet-developers] Linux socket close/unbind mechanisms

[Jan K. <jan...@we...>]

Bruno Carlus wrote:
> Hi all,
> 
> Does anyone know wether it exixts under linux, a mechanism that 
> automatically unbinds and closes a socket not properly released by its 
> parent process ? Could it be apply to RTnet udp socket ?

Linux closes all owned open file descriptors on process termination. And 
so does Xenomai since 2.4. If with this version something still remains 
open (check /proc/xenomai/rtdm/open_fildes), it would be a bug. Please 
report you findings then.

Jan