rtnet-developers — development-related list

[RTnet-developers] [Fwd: [RTnet-users] Kernel 2.4 compilation]

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

Damn auto-completion...

[RTnet-developers] RTnet supports Xenomai 2.1-trunk

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

Hi,

there is now support for the upcoming Xenomai 2.1 version available in
the SVN repository. In case you haven't heard about that development:
the new Xenomai build system links its kernel part into the provided
(and Adeos-patched) kernel source tree. Thus, configuring and building
the Xenomai kernel support takes place *inside* that kernel tree. On the
other hand, all userspace libraries are build independently from the
Xenomai source tree.

For RTnet as a user of the kernel interfaces (RTDM), we basically need
to know of the location of the RT-extended kernel. Only if we build the
examples, we must also know where the header and userspace libs are - by
means of the xeno-config tool.

To differentiate clearly between both building models, the user has to
select if (s)he is using RTAI/Xenomai 2.0.x or Xenomai 2.1 and later.
Then only the required paths are requested: RTAI/Xenomai installation
path for the classic model and the RT-extended kernel path for the new
one. Only if the user decides the build some examples too, the config
tool path is requested as well.

Check out and give it a try!

Jan

Re: [RTnet-developers] Joint Slots patch

[Jan K. <ki...@rt...>]

Vareka, Bill wrote:
> Here is a patch to add the option of joint slots. I have not had a chance to
> fully test this but the changes are fairly confined so this should be good.
> ...

Ok, your patch with some modifications and extensions is in the SVN.
Compiles and /seems/ to run well on top of Xenomai 2.0. It only "seems"
to work as I'm currently too busy to set up a second box, so I only
checked if outgoing packets to nowhere are being scattered across the
new joint slots - they are. 8)

What I did differently: I broke up the lock when traversing the slot
list on cleanup and reconfigure for potential joint slots. I also
applied a stricter check when the head of a slot chain gets changed
(smaller MTU permissible, larger will break up the chain). Moreover, I
added /proc support so that you can see what you configured. ;)

More tests certainly required. I hope to spent some time on this the
next days and then roll out a release candidate for 0.9.0.

Thanks again for your work,
Jan

Re: [RTnet-developers] Joint Slots patch

[Jan K. <ki...@rt...>]

Vareka, Bill wrote:
> Here is a patch to add the option of joint slots. I have not had a chance to
> fully test this but the changes are fairly confined so this should be good.
>

Great work, and also very well described. Thanks for your contribution!

> The basic idea is that you define multiple slots but all but the first are
> defined as 'joined' to the first one.  Then when you write via the socket,
> the data goes to a common slot buffer and is sent in the next assigned slot.
> This can be used to significantly reduce latencies without requiring very
> short cycle periods.
>
> The changes are:
> 1) add a -j option to tdmacfg for 'slots' which takes the joint slot id.  It
> will be required that the slot you want to reference to must have already
> been defined before you define the joint slot.  Also, the mtu's of both
> the slot your joining and your own slot must be the same.
>
> 2) The tdma_config struct adds an additional int field called jointslot to
> the set_slot union.  A value between 0 and MaxSlots indicates a
> desire to be coupled.  Default is -1 (no coupling).
>
> 3) Modify the tdma_slot by changing the 'queue' member to be a pointer to a
> rtskb_prio_queue and add an additional actual rtskb_prio_queue called
> myqueue.
>
> 4) By default, slot->queue just points to &slot->myqueue.
>
> 5) The act of joining is achieved by changing slot->queue to point to
> another pre-existing slot's myqueue member.
>
> 6) the rest of the tdma_slot structs for the two joint slots are not
> identical because this is where things like offset, period and phasing info
> are kept and those are different for the two slots.  Only the
> rtskb_prio_queue is common between them.
>
> 7) If you remove a slot which is jointed to another slot but you're not the
> reference, then you just delete normally.  But if others have queue pointer
> pointing to your myqueue object then all those slots have their queue's
> redirected to their own myqueue objects.  Obviously, care is taken that this
> is done when ref_count is 0 so we don't corrupt a loop in progress.
>
> 8) The only other impact is a few function calls which currently have
> &slot->queue which needed to be changed to slot->queue since it's a pointer
> already.

Looks good. On the first glace I had some concerns regarding the loops
over all slots under spinlock to find potential mates (even when there
are none), but I see no other simple solution so far. Will try to think
about it further, though.

>
> 9) An unrelated bug was addressed, in the original tdma_ioctl.c file on line
> 474 the original code had
>         while ((rtskb = __rtskb_prio_dequeue(&slot->queue)))
> but I believe the correct call should have been
>         while ((rtskb = __rtskb_prio_dequeue(&old_slot->queue)))
> I've incorporated that into this patch as well but it is really independent
> of the joint-slots changes.

Oh, yes, good spot. Looks like some real cleanup bug...

>
> Unlike what I stated in an earlier post, this no longer treats the NRT slot
> any different from the others, thus you can also join to it if you want.
>

Ok, I have some code refactoring still pending on my box which I would
like to finish and check in first, but then it will be your patch's
turn. Should definitely make it into SVN for the next release!

Jan

[RTnet-developers] Joint Slots patch

[Vareka, B. <BV...@am...>]

Here is a patch to add the option of joint slots. I have not had a chance to
fully test this but the changes are fairly confined so this should be good.

The basic idea is that you define multiple slots but all but the first are
defined as 'joined' to the first one.  Then when you write via the socket,
the data goes to a common slot buffer and is sent in the next assigned slot.
This can be used to significantly reduce latencies without requiring very
short cycle periods.

The changes are:
1) add a -j option to tdmacfg for 'slots' which takes the joint slot id.  It
will be required that the slot you want to reference to must have already
been defined before you define the joint slot.  Also, the mtu's of both
the slot your joining and your own slot must be the same.

2) The tdma_config struct adds an additional int field called jointslot to
the set_slot union.  A value between 0 and MaxSlots indicates a
desire to be coupled.  Default is -1 (no coupling).

3) Modify the tdma_slot by changing the 'queue' member to be a pointer to a
rtskb_prio_queue and add an additional actual rtskb_prio_queue called
myqueue.

4) By default, slot->queue just points to &slot->myqueue.  

5) The act of joining is achieved by changing slot->queue to point to
another pre-existing slot's myqueue member.  

6) the rest of the tdma_slot structs for the two joint slots are not
identical because this is where things like offset, period and phasing info
are kept and those are different for the two slots.  Only the
rtskb_prio_queue is common between them.  

7) If you remove a slot which is jointed to another slot but you're not the
reference, then you just delete normally.  But if others have queue pointer
pointing to your myqueue object then all those slots have their queue's
redirected to their own myqueue objects.  Obviously, care is taken that this
is done when ref_count is 0 so we don't corrupt a loop in progress.

8) The only other impact is a few function calls which currently have
&slot->queue which needed to be changed to slot->queue since it's a pointer
already.

9) An unrelated bug was addressed, in the original tdma_ioctl.c file on line
474 the original code had
        while ((rtskb = __rtskb_prio_dequeue(&slot->queue)))
but I believe the correct call should have been
        while ((rtskb = __rtskb_prio_dequeue(&old_slot->queue)))
I've incorporated that into this patch as well but it is really independent
of the joint-slots changes.

Unlike what I stated in an earlier post, this no longer treats the NRT slot
any different from the others, thus you can also join to it if you want.


Regards,
Bill

********* patch ************************


diff -Naur rtnet-0.8.3/stack/include/rtmac/tdma/tdma.h
rtnet-0.8.3new/stack/include/rtmac/tdma/tdma.h
--- rtnet-0.8.3/stack/include/rtmac/tdma/tdma.h	2005-02-28
04:27:34.000000000 -0600
+++ rtnet-0.8.3new/stack/include/rtmac/tdma/tdma.h	2005-08-18
08:39:22.000000000 -0500
@@ -78,7 +78,8 @@
     unsigned int                phasing;
     unsigned int                mtu;
     unsigned int                size;
-    struct rtskb_prio_queue     queue;
+    struct rtskb_prio_queue     *queue;
+    struct rtskb_prio_queue     myqueue;
 };
 
 
diff -Naur rtnet-0.8.3/stack/include/tdma_chrdev.h
rtnet-0.8.3new/stack/include/tdma_chrdev.h
--- rtnet-0.8.3/stack/include/tdma_chrdev.h	2004-11-17
02:09:44.000000000 -0600
+++ rtnet-0.8.3new/stack/include/tdma_chrdev.h	2005-08-18
08:40:02.000000000 -0500
@@ -54,6 +54,7 @@
             unsigned int    period;
             unsigned int    phasing;
             unsigned int    size;
+            int             jointslot;
             unsigned int    cal_timeout;
             __u64           *cal_results;
         } set_slot;
diff -Naur rtnet-0.8.3/stack/rtmac/tdma/tdma_ioctl.c
rtnet-0.8.3new/stack/rtmac/tdma/tdma_ioctl.c
--- rtnet-0.8.3/stack/rtmac/tdma/tdma_ioctl.c	2005-02-28
04:27:34.000000000 -0600
+++ rtnet-0.8.3new/stack/rtmac/tdma/tdma_ioctl.c	2005-08-18
02:54:34.000000000 -0500
@@ -299,7 +299,7 @@
     struct rtskb            *rtskb;
     unsigned int            job_list_revision;
     unsigned long           flags;
-    int                     ret;
+    int                     ret, ii, jntId;
 
 
     if (rtdev->mac_priv == NULL)
@@ -318,6 +318,15 @@
     else if (cfg->args.set_slot.size > rtdev->mtu)
         return -EINVAL;
 
+    jntId = cfg->args.set_slot.jointslot;
+    if(  (jntId >=0 ) &&
+         (    (jntId >= tdma->max_slot_id)
+           || (tdma->slot_table[jntId] == 0)
+           || (tdma->slot_table[jntId]->mtu != cfg->args.set_slot.size)
+         ) )
+        return -EINVAL;
+
+
     slot = (struct tdma_slot *)kmalloc(sizeof(struct tdma_slot),
GFP_KERNEL);
     if (!slot)
         return -ENOMEM;
@@ -402,8 +411,12 @@
     slot->phasing        = cfg->args.set_slot.phasing;
     slot->mtu            = cfg->args.set_slot.size;
     slot->size           = cfg->args.set_slot.size +
rtdev->hard_header_len;
+    slot->queue          = &slot->myqueue;
     rtos_nanosecs_to_time(cfg->args.set_slot.offset, &slot->offset);
-    rtskb_prio_queue_init(&slot->queue);
+    rtskb_prio_queue_init(slot->queue);
+
+    if(jntId >=0 )  //all other validation tests performed above.
+        slot->queue  = tdma->slot_table[jntId]->queue;
 
     old_slot = tdma->slot_table[id];
     if ((id == DEFAULT_NRT_SLOT) &&
@@ -454,13 +467,27 @@
         (tdma->slot_table[DEFAULT_NRT_SLOT] == old_slot))
         tdma->slot_table[DEFAULT_NRT_SLOT] = slot;
 
-    if (old_slot)
+    if (old_slot) {
         while (old_slot->head.ref_count > 0) {
             rtos_spin_unlock_irqrestore(&tdma->lock, flags);
             set_current_state(TASK_UNINTERRUPTIBLE);
             schedule_timeout(HZ/10); /* wait 100 ms */
             rtos_spin_lock_irqsave(&tdma->lock, flags);
         }
+        //if others were linked to my prio que, move them to the new one.
+        for(ii=0; ii<tdma->max_slot_id; ii++) {
+            if( (tdma->slot_table[ii] != 0)
+                && (tdma->slot_table[ii]->queue == &old_slot->myqueue)) {
+                while (tdma->slot_table[ii]->head.ref_count > 0) {
+                    rtos_spin_unlock_irqrestore(&tdma->lock, flags);
+                    set_current_state(TASK_UNINTERRUPTIBLE);
+                    schedule_timeout(HZ/10); /* wait 100 ms */
+                    rtos_spin_lock_irqsave(&tdma->lock, flags);
+                } //end while, safe to change queue pointer
+                tdma->slot_table[ii]->queue = slot->queue;
+            }
+        }
+    }
 
     rtos_spin_unlock_irqrestore(&tdma->lock, flags);
 
@@ -471,7 +498,8 @@
            without lock protection.
            NOTE: Reconfiguring a slot during runtime may lead to packet
                  drops! */
-        while ((rtskb = __rtskb_prio_dequeue(&slot->queue)))
+        old_slot->queue = &old_slot->myqueue;
+        while ((rtskb = __rtskb_prio_dequeue(old_slot->queue)))
             kfree_rtskb(rtskb);
 
         kfree(old_slot);
@@ -501,10 +529,24 @@
     if (id == DEFAULT_NRT_SLOT)
         tdma->slot_table[DEFAULT_NRT_SLOT] =
tdma->slot_table[DEFAULT_SLOT];
     else {
+        int ii;
         if ((id == DEFAULT_SLOT) &&
             (tdma->slot_table[DEFAULT_NRT_SLOT] == slot))
             tdma->slot_table[DEFAULT_NRT_SLOT] = NULL;
         tdma->slot_table[id] = NULL;
+          //search for other slots linked to my queue and detach them
+        for(ii=0; ii<tdma->max_slot_id; ii++) {
+            if(  (tdma->slot_table[ii] != 0) &&
+                 (tdma->slot_table[ii]->queue == &slot->myqueue)) {
+                while (tdma->slot_table[ii]->head.ref_count > 0) {
+                    rtos_spin_unlock_irqrestore(&tdma->lock, flags);
+                    set_current_state(TASK_UNINTERRUPTIBLE);
+                    schedule_timeout(HZ/10); /* wait 100 ms */
+                    rtos_spin_lock_irqsave(&tdma->lock, flags);
+                } //end while, safe to move queue pointer
+                tdma->slot_table[ii]->queue =
&tdma->slot_table[ii]->myqueue;
+            }
+        }
     }
 
     while (slot->head.ref_count > 0) {
@@ -518,7 +560,8 @@
 
     /* No need to protect the queue access here -
        no one is referring to this job anymore (ref_count == 0). */
-    while ((rtskb = __rtskb_prio_dequeue(&slot->queue)))
+    slot->queue = &slot->myqueue;
+    while ((rtskb = __rtskb_prio_dequeue(slot->queue)))
         kfree_rtskb(rtskb);
 
     kfree(slot);
diff -Naur rtnet-0.8.3/stack/rtmac/tdma/tdma_proto.c
rtnet-0.8.3new/stack/rtmac/tdma/tdma_proto.c
--- rtnet-0.8.3/stack/rtmac/tdma/tdma_proto.c	2005-02-28
04:27:34.000000000 -0600
+++ rtnet-0.8.3new/stack/rtmac/tdma/tdma_proto.c	2005-08-18
09:00:04.000000000 -0500
@@ -155,7 +155,7 @@
         goto err_out;
     }
 
-    __rtskb_prio_queue_tail(&slot->queue, rtskb);
+    __rtskb_prio_queue_tail(slot->queue, rtskb);
 
   err_out:
     rtos_spin_unlock_irqrestore(&tdma->lock, flags);
@@ -193,7 +193,7 @@
         goto err_out;
     }
 
-    __rtskb_prio_queue_tail(&slot->queue, rtskb);
+    __rtskb_prio_queue_tail(slot->queue, rtskb);
 
   err_out:
     rtos_spin_unlock_irqrestore(&tdma->lock, flags);
diff -Naur rtnet-0.8.3/stack/rtmac/tdma/tdma_worker.c
rtnet-0.8.3new/stack/rtmac/tdma/tdma_worker.c
--- rtnet-0.8.3/stack/rtmac/tdma/tdma_worker.c	2004-12-06
02:10:44.000000000 -0600
+++ rtnet-0.8.3new/stack/rtmac/tdma/tdma_worker.c	2005-08-18
09:00:48.000000000 -0500
@@ -58,7 +58,7 @@
                 rtos_task_sleep_until(&time);
 
                 rtos_spin_lock_irqsave(&tdma->lock, flags);
-                rtskb = __rtskb_prio_dequeue(&SLOT_JOB(job)->queue);
+                rtskb = __rtskb_prio_dequeue(SLOT_JOB(job)->queue);
                 if (!rtskb)
                     goto continue_in_lock;
                 rtos_spin_unlock_irqrestore(&tdma->lock, flags);
diff -Naur rtnet-0.8.3/tools/tdmacfg.c rtnet-0.8.3new/tools/tdmacfg.c
--- rtnet-0.8.3/tools/tdmacfg.c	2004-12-02 03:39:38.000000000 -0600
+++ rtnet-0.8.3new/tools/tdmacfg.c	2005-08-18 09:05:38.000000000 -0500
@@ -44,7 +44,7 @@
         "\t        [-m max_calibration_requests]\n"
         "\ttdmacfg <dev> slave [-c calibration_rounds] [-i max_slot_id]\n"
         "\ttdmacfg <dev> slot <id> [<offset> [-p <phasing>/<period>] "
-            "[-s <size>]\n"
+            "[-s <size>] [-j <joint_slot_id>]\n"
         "\t         [-l calibration_log_file] [-t calibration_timeout]]\n"
         "\ttdmacfg <dev> detach\n");
 
@@ -60,7 +60,7 @@
 
     if (pos >= argc)
         help();
-    if ((sscanf(argv[pos], "%u", &result) != 1) || (result < min)) {
+    if ((sscanf(argv[pos], "%i", &result) != 1) || (result < min)) {
         fprintf(stderr, "invalid parameter: %s %s\n", argv[pos-1],
argv[pos]);
         exit(1);
     }
@@ -208,6 +208,7 @@
         tdma_cfg.args.set_slot.phasing     = 0;
         tdma_cfg.args.set_slot.size        = 0;
         tdma_cfg.args.set_slot.cal_timeout = 0;
+        tdma_cfg.args.set_slot.jointslot   = -1;
         tdma_cfg.args.set_slot.cal_results = NULL;
 
         for (i = 5; i < argc; i++) {
@@ -236,6 +237,9 @@
             else if (strcmp(argv[i], "-t") == 0)
                 tdma_cfg.args.set_slot.cal_timeout =
                     getintopt(argc, ++i, argv, 0);
+            else if (strcmp(argv[i], "-j") == 0)
+                tdma_cfg.args.set_slot.jointslot =
+                    getintopt(argc, ++i, argv, -1);
             else
                 help();
         }

[RTnet-developers] make menuconfig

[Jan K. <ki...@rt...>]

Hi,

you are welcome to test a new feature of RTnet:

make menuconfig|xconfig|oldconfig |...
(just as you know it from the kernel or RTAI)

This should make the management of the increasing numbers of config
options a bit easier (e.g. you can now switch off IPv4 support).

Jan

Re: [RTnet-developers] Gigabit driver RTL8169

[Jan K. <ki...@rt...>]

Klaus Keppler wrote:
> Hello,
> 
> attached you find the first Gigabit Ethernet driver for RTnet.

Merged into SVN. Please check if it still works.

Jan

Re: [RTnet-developers] Gigabit driver RTL8169

[Jan K. <ki...@rt...>]

Klaus Keppler wrote:
> Hi Jan,
> 
>> I was trying to merge your patch into SVN, but I ran into some troubles
>> because the patch contains a rt_r8169_n.c file (instead of plain
>> rt_r8169.c). Just rename it?
> 
> 
> No problem, that's just a historic issue (Realtek's original driver
> is named 'rt_r8169_n.c'). Don't know what the '_n' stands for... :-/
> 

I'm making progress with the merge but I stumbled over a few issues when
compiling against a 2.6.12. Some were related to changes in SVN, and
most were easy to fix. But this one remained:

rt_r8169.c:689: SET_NETDEV_DEV(rtdev, &pdev->dev);

This cannot work as the macro addresses a field of net_device
rtnet_device does not provide. Are you compiling against 2.4??? Anyway,
is disabling of that line ok?

> I'll try to continue working with a SVN snapshot the next days...
> 

Ok, but you should note that SVN so far only works with fusion-CVS
respectively the soon-to-be-released version 0.9. RTAI/classic support
is still searching for a contributor.

Jan

Re: [RTnet-developers] Gigabit driver RTL8169

[Klaus K. <kla...@in...>]

Hi Jan,

> I was trying to merge your patch into SVN, but I ran into some troubles
> because the patch contains a rt_r8169_n.c file (instead of plain
> rt_r8169.c). Just rename it?

No problem, that's just a historic issue (Realtek's original driver
is named 'rt_r8169_n.c'). Don't know what the '_n' stands for... :-/

I'll try to continue working with a SVN snapshot the next days...


    Klaus

-- 
Institut für Informatik
Friedrich-Alexander-Universität Erlangen-Nürnberg
http://www.cs.fau.de

Re: [RTnet-developers] Gigabit driver RTL8169

[Jan K. <ki...@rt...>]

Klaus Keppler wrote:
> Hello,
> 
> attached you find the first Gigabit Ethernet driver for RTnet.

Really fine work. Thanks for the contribution!

> It is a patch against RTnet-0.8.3 and supports NICs based on the
> Realtek RTL-8169 chipset. This driver was developed and tested
> using two D-Link DGE-528T cards and a D-Link 5port Gigabit Switch
> (have a look at the DGE-910 package from D-Link).
> The driver is based on the latest sources from Realtek with some
> important backports from the r8169 driver in the 2.6.12 kernel.
> 
> Jumbo frames are not yet supported, as the MTU size within the
> RTnet core would have to be adjusted for this, but I'm on it. :-)
> 
> In the next weeks I'll hopefully present the next GigE driver
> (then for Intel chipsets).
> 
> If one of you has the possibility to also test this driver or have
> a look at it I'd be thankful for your feedback.
> 

I was trying to merge your patch into SVN, but I ran into some troubles
because the patch contains a rt_r8169_n.c file (instead of plain
rt_r8169.c). Just rename it?

Jan

[RTnet-developers] Gigabit driver RTL8169

[Klaus K. <kla...@in...>]

Hello,

attached you find the first Gigabit Ethernet driver for RTnet.
It is a patch against RTnet-0.8.3 and supports NICs based on the
Realtek RTL-8169 chipset. This driver was developed and tested
using two D-Link DGE-528T cards and a D-Link 5port Gigabit Switch
(have a look at the DGE-910 package from D-Link).
The driver is based on the latest sources from Realtek with some
important backports from the r8169 driver in the 2.6.12 kernel.

Jumbo frames are not yet supported, as the MTU size within the
RTnet core would have to be adjusted for this, but I'm on it. :-)

In the next weeks I'll hopefully present the next GigE driver
(then for Intel chipsets).

If one of you has the possibility to also test this driver or have
a look at it I'd be thankful for your feedback.

Best regards,

    Klaus

-- 
Institut für Informatik
Friedrich-Alexander-Universität Erlangen-Nürnberg
http://www.cs.fau.de

[RTnet-developers] Re: [proposal] making use of module symbols

[Jan K. <ki...@rt...>]

Philippe Gerum wrote:
> Jan Kiszka wrote:
>
>> Philippe Gerum wrote:
>>
>>> ...
>>> Good idea. Just implemented as described, now in the CVS. Thanks for the
>>> hint. Additional testing welcome.
>>>
>>> PS: *.mod files contents refer to the build directory, so I guess that
>>> such information would not be useful for setups that only provide the
>>> installed binaries (and not the initial build dir). But still, I have
>>> nonetheless exported the symbols to $exec_prefix/symbols as proposed.
>>>
>>
>>
>> That's good news. I started playing a bit with it and have two remarks
>> so far:
>>
>> 1. As it seems that we will no longer be able to build *modules* against
>> RTAI just by using the files from the installation directory, I see no
>
>
> Why? I mean, I don't see the difference wrt the previous situation. We
> can still build modules only using the installed stuff and the kernel
> tree in any case, we just get the Kbuild warnings unless we have the
> symbols available from the initial fusion build dir. I've just tried
> that after having removed the build dir, and it's ok.

I thought the PPC issues were severer than just warnings. Anyway,
reasonable development is not possible with all those warnings around
again, and that's what made me draw the line.

>
>> need anymore to actually install the symbol files. Creating a link, just
>> like "build", for "symbols" should be ok.
>>
>
> Agreed; as said earlier, the .mod files only contain pointers to the
> build dir anyway, so a symlink would be enough.
>
>> 2. Should external projects assume that the symbol dir is always
>> "symbols", or should rtai-config be extended to return it? I'm in no
>> favour for any of the options, I just would like to know which one to
>> implement.
>
>
> rtai-config --symbol-dir (for consistency reason, since we already have
> --module-dir).
>

The new concept has been adapted to RTnet now and is part of its SVN
repos. Anyone interested in autotool-based module builds against fusion
is invited to have a look and steal ideas.

Short description: RTnet creates a "symbols" dir in its build dir, then
links all files found in fusion's symbols dir to its own. Thus, all
*.mod files are gathered during the RTnet build aside those links in
RTnet's private symbols dir, and this one can easily be passed to the
kernel build command via MODVERDIR. On "make distclean", and that's an
extension fusion may want to gain as well, the *.mod files of the
respective module are removed from the central symbols dir again.

This model should even work when being extended by another indirection:
the eth-over-1394 driver of RTnet has to be built against the (external)
RT-FireWire project, which is also build against fusion of course. Now,
when providing that project dir via --with-rtfw, RTnet should rather
collect links and symbols from a (future) RT-FireWire symbols dir and
put them into its own. This would allow to stack projects respecting
their symbol dependencies.

Yuchen [RT-FireWire maintainer], if you are listening: you are likely
busy with other things right now, but we should keep this in mind and
check later if it is feasible.


Besides all this autotool stuff, here is a concept for "plain" external
module builds. For that purpose, I extended the GNUmakefile of rt_cifibm
(the recently published InterBus driver) as follows:

1. Introduced the variable

   SYMBOL_DIR = $(shell $(FUSIONDIR)/bin/rtai-config --symbol-dir)


2. Added

   MODVERDIR=$$PWD/symbols

   to the module make command and let it additionally depend on the
   target "symbols"


3. Added the target symbols

   symbols:
           @mkdir -p symbols
           @rm -rf symbols/*
           @for FILE in `ls $(SYMBOL_DIR)/*`; do \
               ln -s $$FILE symbols/`basename $$FILE`; \
           done


4. Cleaned up "symbols" on "make clean" (instead of ".tmp_versions")

A modified version of the driver package will be uploaded to my page soon.

Jan

Re: [RTnet-developers] Joint threads

[Vareka, B. <BV...@am...>]

> Vareka, Bill wrote:
>> I moved this over from Rtnet-users because this seems the more
appropriate
>> board.  Yes, I have thought about how to do this and at the moment I've
>> written a first stab at the code but I have yet to put together a system
to
>> test it on.  The crux of the changes are as follows:
>> 1) add a -j option to tdmacfg for 'slots' which takes the joint slot id.
It
>> will be required that the slot you want to reference to must have already
>> been defined before you define the joint slot.  Had not yet though about
the
>> actual tdma.conf file but this should be pretty straight forward.
>> 
>> 2) The tdma_config struct adds an additional int field called jointslot
to
>> the set_slot union.  A value between 0 and MaxSlots (but not 1) indicates
a
>> desire to be coupled.  Default is -1 (no coupling).
>> 
>> 3) Because of the special role of the default NRT slot (1) and the fact
that
>> a mechanism already exists for it to 'share' slot 0, I have strictly
>> forbidden the option to link slot 1 to other slots or other slots to it.
>> Also, since it's already NRT, there is no likely benefit in jointing it
to
>> other slots for speed and latency purposes. 
>> 
> 
> But slot 0 and 1 will not form a super-slot this way, thus there will be
> no higher bandwidth available for NRT traffic. I wouldn't forbid the
> option to create joint NRT slots, as long as no technical reasons
> complicat this (e.g have negativ impact on RT slots). There might be
> users some day who could need it.
>

Actually the real constraint was that the way that the NRT maps back and
forth to slot 0 means that a fair amount of extra checking has to happen to
keep that working as before.  I'll look some more and see how much extra
complication is involved. You're right though, this could be used to provide
extra NRT bandwidth. I hadn't thought of that. 
 
> But I think there is some other constraint: all slots to be coupled
> should have the same size. Otherwise it would be tricky to return the
> slot group's MTU to higher layers and to deal with packets not fitting
> into some of the slots.
> 

Yes, this is another check that should be applied.  If the slot size of a
joining slot is not the same as that of the reference, then the join is
aborted and the ioctl call fails.  

>> 4) Modify the tdma_slot by changing the 'queue' member to be a pointer to
a
>> rtskb_prio_queue and add an additional actual rtskb_prio_queue called
>> myqueue.
>> 
>> 5) By default, slot->queue just points to &slot->myqueue.  
>> 
>> 6) The act of joining is achieved by changing slot->queue to point to
>> another pre-existing slot's myqueue member.  
>> 
>> 7) the rest of the tdma_slot structs for the two joint slots are not
>> identical because this is where things like offset, period and phasing
info
>> are kept and those are different for the two slots.  Only the
>> rtskb_prio_queue is common between them.  Note that I didn't really
>> appreciate this until I looked closely at the NRT example.  There things
are
>> different because there never really is a slot 1 for the default case but
>> here we want the slots to really exist, we just want them to use the same
>> message queue.
>> 
>> 8) If you remove a slot which is jointed to another slot but you're not
the
>> reference, then you just delete normally.  But if others have queue
pointer
>> pointing to your myqueue object then all those slots have their queue's
>> redirected to their own myqueue objects.  Obviously, care is taken that
this
>> is done when ref_count is 0 so we don't corrupt a loop in progress.
>> 
>> 9) The only other impact is a few function calls which currently have
>> &slot->queue which need to be changed to slot->queue since it's a pointer
>> already.
>> 
>> As is typical, I've got several other high priority projects going at
once
>> so I suspect I won't have this tested and ready for a week or so.
>> 
> 
> This all sounds very reasonible and feasible to me. And you don't have
> to hurry with your patch, the next RTnet release will still take some
> time (among other aspects, it depends on fusion's 0.9 release and a
> potential classic port).
> 
> Jan
>

Re: [RTnet-developers] Joint threads

[Jan K. <ki...@rt...>]

Vareka, Bill wrote:
> I moved this over from Rtnet-users because this seems the more appropriate
> board.  Yes, I have thought about how to do this and at the moment I've
> written a first stab at the code but I have yet to put together a system to
> test it on.  The crux of the changes are as follows:
> 1) add a -j option to tdmacfg for 'slots' which takes the joint slot id.  It
> will be required that the slot you want to reference to must have already
> been defined before you define the joint slot.  Had not yet though about the
> actual tdma.conf file but this should be pretty straight forward.
> 
> 2) The tdma_config struct adds an additional int field called jointslot to
> the set_slot union.  A value between 0 and MaxSlots (but not 1) indicates a
> desire to be coupled.  Default is -1 (no coupling).
> 
> 3) Because of the special role of the default NRT slot (1) and the fact that
> a mechanism already exists for it to 'share' slot 0, I have strictly
> forbidden the option to link slot 1 to other slots or other slots to it.
> Also, since it's already NRT, there is no likely benefit in jointing it to
> other slots for speed and latency purposes. 
> 

But slot 0 and 1 will not form a super-slot this way, thus there will be
no higher bandwidth available for NRT traffic. I wouldn't forbid the
option to create joint NRT slots, as long as no technical reasons
complicat this (e.g have negativ impact on RT slots). There might be
users some day who could need it.

But I think there is some other constraint: all slots to be coupled
should have the same size. Otherwise it would be tricky to return the
slot group's MTU to higher layers and to deal with packets not fitting
into some of the slots.

> 4) Modify the tdma_slot by changing the 'queue' member to be a pointer to a
> rtskb_prio_queue and add an additional actual rtskb_prio_queue called
> myqueue.
> 
> 5) By default, slot->queue just points to &slot->myqueue.  
> 
> 6) The act of joining is achieved by changing slot->queue to point to
> another pre-existing slot's myqueue member.  
> 
> 7) the rest of the tdma_slot structs for the two joint slots are not
> identical because this is where things like offset, period and phasing info
> are kept and those are different for the two slots.  Only the
> rtskb_prio_queue is common between them.  Note that I didn't really
> appreciate this until I looked closely at the NRT example.  There things are
> different because there never really is a slot 1 for the default case but
> here we want the slots to really exist, we just want them to use the same
> message queue.
> 
> 8) If you remove a slot which is jointed to another slot but you're not the
> reference, then you just delete normally.  But if others have queue pointer
> pointing to your myqueue object then all those slots have their queue's
> redirected to their own myqueue objects.  Obviously, care is taken that this
> is done when ref_count is 0 so we don't corrupt a loop in progress.
> 
> 9) The only other impact is a few function calls which currently have
> &slot->queue which need to be changed to slot->queue since it's a pointer
> already.
> 
> As is typical, I've got several other high priority projects going at once
> so I suspect I won't have this tested and ready for a week or so.
> 

This all sounds very reasonible and feasible to me. And you don't have
to hurry with your patch, the next RTnet release will still take some
time (among other aspects, it depends on fusion's 0.9 release and a
potential classic port).

Jan

[RTnet-developers] Joint threads

[Vareka, B. <BV...@am...>]

I moved this over from Rtnet-users because this seems the more appropriate
board.  Yes, I have thought about how to do this and at the moment I've
written a first stab at the code but I have yet to put together a system to
test it on.  The crux of the changes are as follows:
1) add a -j option to tdmacfg for 'slots' which takes the joint slot id.  It
will be required that the slot you want to reference to must have already
been defined before you define the joint slot.  Had not yet though about the
actual tdma.conf file but this should be pretty straight forward.

2) The tdma_config struct adds an additional int field called jointslot to
the set_slot union.  A value between 0 and MaxSlots (but not 1) indicates a
desire to be coupled.  Default is -1 (no coupling).

3) Because of the special role of the default NRT slot (1) and the fact that
a mechanism already exists for it to 'share' slot 0, I have strictly
forbidden the option to link slot 1 to other slots or other slots to it.
Also, since it's already NRT, there is no likely benefit in jointing it to
other slots for speed and latency purposes. 

4) Modify the tdma_slot by changing the 'queue' member to be a pointer to a
rtskb_prio_queue and add an additional actual rtskb_prio_queue called
myqueue.

5) By default, slot->queue just points to &slot->myqueue.  

6) The act of joining is achieved by changing slot->queue to point to
another pre-existing slot's myqueue member.  

7) the rest of the tdma_slot structs for the two joint slots are not
identical because this is where things like offset, period and phasing info
are kept and those are different for the two slots.  Only the
rtskb_prio_queue is common between them.  Note that I didn't really
appreciate this until I looked closely at the NRT example.  There things are
different because there never really is a slot 1 for the default case but
here we want the slots to really exist, we just want them to use the same
message queue.

8) If you remove a slot which is jointed to another slot but you're not the
reference, then you just delete normally.  But if others have queue pointer
pointing to your myqueue object then all those slots have their queue's
redirected to their own myqueue objects.  Obviously, care is taken that this
is done when ref_count is 0 so we don't corrupt a loop in progress.

9) The only other impact is a few function calls which currently have
&slot->queue which need to be changed to slot->queue since it's a pointer
already.

As is typical, I've got several other high priority projects going at once
so I suspect I won't have this tested and ready for a week or so.



Regards,
Bill



-----Original Message-----
From: Jan Kiszka [mailto:ki...@rt...] 
Sent: Tuesday, August 16, 2005 4:37 PM
To: Vareka, Bill
Cc: 'rtn...@li...'
Subject: Re: [RTnet-users] Slots, threads, and all that.

Vareka, Bill wrote:
> I just finished adding a section to the rtai wiki on rtnet.  The link is
> http://www.rtai.dk/cgi-bin/gratiswiki.pl?RTnet

Thanks for your contribution!

> I needed to work through how slots, slot buffers, threads, sockets, and
> priorities worked so that I could figure out how to meet my fairly severe
> scheduling needs.  Needless to say, this was a bit of a challenge but I

:)

Good work!

> believe I have correctly captured the standard RTmac/TDMA implementation.
If
> you're interested, give it a read and if there is anything I got wrong,
let
> me know.

As it's a wiki, I dared to mess around a bit. I removed some obsolete
stuff, straightened some terms and added a few explanations. No
guarantees as well, it was a quick hack.

Your commitment on a TDMA extension regarding "joint slots", as I would
call it now, will be warmly welcome! Do you already have an idea, how to
extend the configuration interface (tdmacfg)? Also, some syntax
extension for tdma.cfg would be useful. My spontaneous idea would be to
assign further slots to an existing one be means of an additional
tdmacfg parameter expecting the target slot id.

Looking forward to your patch! If questions regarding the TDMA code etc.
arrise, feel free to ask.

Jan

Re: [RTnet-developers] Interrupt sharing realtime / non-realtime

[Jan K. <ki...@rt...>]

Klaus Keppler wrote:
> That's clear - but I wasn't sure if there's really a problem
> whith shared interrupts.
> 
> In the meantime I swapped my "new" NICs with some via-rhine based
> cards and experienced the same problem when sharing interrupts.
> (so I proved that there's no bug in my freshly ported driver...)
> 
> Concluding I can say that RTnet (+RTAI) can't be used on NICs
> which share their interrupt with non-realtime NICs (which are
> in use at the same time).
> 

The problem with sharing IRQ line between RT and non-rt drivers is that
the non-RT driver at least has to be given the chance to acknowledge and
switch off the IRQ source on its related device. Otherwise, the IRQ line
will remain active, shadowing any IRQ from the RT device.

I once made Philippe to add the required infrastructure to Adeos. It now
takes a specifically patched non-RT driver to register a real-time-safe
acknowledge handler with Adeos to quickly release the IRQ line again.
Not trivial.

The reason we once thought we need it was some nice PC104+ NIC which
shared the same IRQ line than the onboard NIC of the attached embedded
PC. As it finally turned out that we had to change some other jumper
than the one labelled with "IRQ No." to actually switch the line (really
a great piece of hardware...), we no longer had to solve it in software.

Jan

Re: [RTnet-developers] TTL

[Jan K. <ki...@rt...>]

amine wrote:
> Hi Jean,
> I have a simple question about the IP TTL value, why are you using a fixed 
> value (255)? 

Actually: I don't remember :). I guess we just had to set /some/ value,
and we still have no applications in sight where real-time packets gets
routed across several networks.

> In multicast we need to change this value , so i have add(in next realise of 
> multicast patch) a new filed in rtsocket structure a "mc_ttl " whitch allow 
> us to change the TLL value from the setsockopt function 
> (RT_IP_MULTICAST_TTL).
> So if you want i can't do the same thing for a normal TTL value, whitch we can 
> change it on using setsocket whith  (RT_IP_TTL).
> So tell me what?
> 

Hmm, do you see a RTnet application where non-multicast IP packets need
customised TTL values? If you need it, feel free to add it. Otherwise, I
would not spent any code on it yet.

Jan

[RTnet-developers] TTL

[amine <am...@an...>]

Hi Jean,
I have a simple question about the IP TTL value, why are you using a fixed 
value (255)? 
In multicast we need to change this value , so i have add(in next realise of 
multicast patch) a new filed in rtsocket structure a "mc_ttl " whitch allow 
us to change the TLL value from the setsockopt function 
(RT_IP_MULTICAST_TTL).
So if you want i can't do the same thing for a normal TTL value, whitch we can 
change it on using setsocket whith  (RT_IP_TTL).
So tell me what?

-- 
EL HEDADI Amine
R&D
phone : 
Email : am...@an...

Re: [RTnet-developers] Interrupt sharing realtime / non-realtime

[Klaus K. <kla...@in...>]

That's clear - but I wasn't sure if there's really a problem
whith shared interrupts.

In the meantime I swapped my "new" NICs with some via-rhine based
cards and experienced the same problem when sharing interrupts.
(so I proved that there's no bug in my freshly ported driver...)

Concluding I can say that RTnet (+RTAI) can't be used on NICs
which share their interrupt with non-realtime NICs (which are
in use at the same time).


    Klaus

Zhang Yuchen schrieb:

> The most straightforward way:
> 
> Open your box, plug one NIC to another PCI slot. Keep on trying, until the
> two use dfferent IRQ.
> 
> Yuchen


-- 
Institut für Informatik
Friedrich-Alexander-Universität Erlangen-Nürnberg
http://www.cs.fau.de

RE: [RTnet-developers] Interrupt sharing realtime / non-realtime

[Zhang Y. <y.z...@st...>]

The most straightforward way:

Open your box, plug one NIC to another PCI slot. Keep on trying, until =
the
two use dfferent IRQ.

Yuchen

> -----Original Message-----
> From: rtn...@li...=20
> [mailto:rtn...@li...] On=20
> Behalf Of Klaus Keppler
> Sent: Thursday, August 04, 2005 11:20 AM
> To: rtn...@li...
> Subject: [RTnet-developers] Interrupt sharing realtime / non-realtime
>=20
> Hello,
>=20
> I'm actually porting drivers for RTnet (hope to tell you more=20
> in some days). But now I have a *real* problem...
>=20
> In one of my development PCs are two NICs: one for "normal"
> ethernet operation, and one as the RTnet interface.
> (Different chipsets, different drivers)
> After several hours (days) of debugging I found out that my=20
> system hangs up when my new RTnet driver is enabled and a=20
> packet on the "normal" interface arrives. I looked into the=20
> PCI table and: yes, these two f*cking NICs share their=20
> interrupt request line (IRQ 10).
>=20
> As I'm relative new to realtime development, I suppose that=20
> it's not possible to share an IRQ between realtime and=20
> non-realtime domains?
> Nevertheless I think that it's the job of Adeos to handle the=20
> interrupts, and when an IRQ 10 is raised, it should first be=20
> handled by RTAI and then (if remaining unhandled) by the=20
> "normal" linux... or not?
> However - I added debugging output to my new driver interrupt=20
> handler to see whenever an interrupt arrives; indeed only=20
> local interrupts of the new RTnet drivers are shown, but when=20
> my "killing" packet (from the normal NIC) arrives, the system=20
> hangs immediately.
>=20
> Currently I'm using RTnet-0.8.3 and RTAI-3.2.
>=20
> Any ideas?
>=20
> Best regards,
>=20
>     Klaus
>=20
> --
> Institut f=FCr Informatik
> Friedrich-Alexander-Universit=E4t Erlangen-N=FCrnberg =
http://www.cs.fau.de
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development=20
> Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *=20
> Testing & QA
> Security * Process Improvement & Measurement *=20
> http://www.sqe.com/bsce5sf
> _______________________________________________
> RTnet-developers mailing list
> RTn...@li...
> https://lists.sourceforge.net/lists/listinfo/rtnet-developers
>=20

[RTnet-developers] Interrupt sharing realtime / non-realtime

[Klaus K. <kla...@in...>]

Hello,

I'm actually porting drivers for RTnet (hope to tell you more in
some days). But now I have a *real* problem...

In one of my development PCs are two NICs: one for "normal"
ethernet operation, and one as the RTnet interface.
(Different chipsets, different drivers)
After several hours (days) of debugging I found out that my
system hangs up when my new RTnet driver is enabled and a
packet on the "normal" interface arrives. I looked into
the PCI table and: yes, these two f*cking NICs share their
interrupt request line (IRQ 10).

As I'm relative new to realtime development, I suppose that
it's not possible to share an IRQ between realtime and
non-realtime domains?
Nevertheless I think that it's the job of Adeos to handle the
interrupts, and when an IRQ 10 is raised, it should first
be handled by RTAI and then (if remaining unhandled) by
the "normal" linux... or not?
However - I added debugging output to my new driver interrupt
handler to see whenever an interrupt arrives; indeed only
local interrupts of the new RTnet drivers are shown, but
when my "killing" packet (from the normal NIC) arrives, the
system hangs immediately.

Currently I'm using RTnet-0.8.3 and RTAI-3.2.

Any ideas?

Best regards,

    Klaus

-- 
Institut für Informatik
Friedrich-Alexander-Universität Erlangen-Nürnberg
http://www.cs.fau.de

[RTnet-developers] RT_8139too driver patch r1

[amine <am...@an...>]

Hi Jean,
I have made some change in 8239too driver and test it , it work well.
I think now changing multicast addresses will not clash with the real-time 
operation of the NIC.
If it need some thing else  , please tell me what 

Best regard

-- 
EL HEDADI Amine
R&D
phone : 
Email : am...@an...

Re: [RTnet-developers] Patch for multicast support for RTnet

[amine <am...@an...>]

On Monday 25 July 2005 16:37, Jan Kiszka wrote:
> Hi Amine,
>
> > hi ,
> >
> > Here the first realise of patch for multicast support in RTnet , This
> > realise support :
> > * IGMP V2
> >
> > I have only adapt the NIC drivers for :
> > *RT_8139too  : Tested
> > *RT_eepro100  : Not Tested
> >
> > -HOW TO USE IT ;
> >      1- Apply the patch to rtnet : (0.8.1 - 0.8.2 - 0.8.3)
> >      2- Patch the NIC driver
> >      3- Execute the autogen.sh scritp to generate a new configure file.
> > (a new config option will added "--enable-multicast" )
> >      4-execute configure   "./configure --with-rtai=<RTAI-DIR>
> > --enable-multicast "
> >
> > Now in your application if you want to receive multicast packets  you
> > must use setsockopt  " RT_IP_ADD_MEMBERSHIP " , to stop the reception of
> > multicast packet you can use "RT_IP_DROP_MEMBERSHIP"
> >
> > Don't forget when sending multicast packet to specify the local IP
> > adress, don't use INADDR_ANY (Only way I've fount to locate the device) .
> >
> > for more detail about use of multicast in RTNET please see the sample
> > attached to this mail.
> >
> > I hope if any body can test this patch ,and if you have any idea to
> > improve it.
> >
> > Im working now on a new realize of this patch , I will  add :
> > * the possiblity to modify the TLL value( new IOCTL in the socketopt).
> > * IGMP V1 Support.
> > * A random response to the query request (IGMP  V1 & V2).
>
> Great! Thanks for the patch, it looks very good. So far I only
> cross-read parts of it. Let's see if you got the implications of this
> multicast patch correctly:
>
>   o Joining or leaving a multicast group can be performed from
>     non-real-time context. Are those IOCTLs (or should they once become
>     socket options?) compatible with the linux multicast interface, or
>     does that one work differently?
I have just use IOCTL  for testing , but to be compatible with linux we must 
use socket options .
We can  use socket otions to ADD or DROP member .IOCTL can become socket 
option without a big change. 
>
>   o Routing is as simple as finding the NIC a socket is bound to via its
>     source address.
Yes . Im  traying to find other solution to do that to avoid the hook in UDP 
send message
>
>   o It take a periodic rt-task to send some "keep-alive" igmp message
>     every 500 ms with low priority (how long may this message be delayed
>     until switches start to drop the membership?). Is this also required
>     in case I'm connected to hubs or an unmanaged switches?
With hub its not required , only with managed switches. I think i will change 
that by using simple task activated by sem event when reciving IGMP query. 
normaly we receive an IGMP query from switch every 125 s. 
The message can be delayed  in 10s.
> The patch is very unintrusive to the core, especially when
> CONFIG_RTNET_MULTICAST is not selected. Therefore, I will see if we can
> merge into SVN soon. But I have two tiny criticisms:
I hope so. 
>
>   o The handling of RT_IP_ADD_MEMBERSHIP and RT_IP_DROP_MEMBERSHIP should
>     check for the correct context (non-RT), and it should be moved to the
>     IP subsystem (rt_ip_ioctl or even rt_ip_setsockopt).
I can move it to rt_ip_ioctl or rt_ip_setsockopt as you like.
>   o Please review your driver patches if changing multicast addresses
>     does not clash with the real-time operation of the NIC. At least
>     the multicast set funtion of the rt_8139 does not seem to use the
>     correct locking functions yet and uses printks within critical
>     sections (note that it has not been used in parallel with RT-parts of
>     the driver so far). Let me know if you need some hints in this
>     respect.
Ok I will check it. 
> Thanks again,
> Jan
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> RTnet-developers mailing list
> RTn...@li...
> https://lists.sourceforge.net/lists/listinfo/rtnet-developers

-- 
EL HEDADI Amine
R&D
phone : 
Email : am...@an...

Re: [RTnet-developers] Patch for multicast support for RTnet

[Jan K. <ki...@rt...>]

Hi Amine,

> hi ,
> 
> Here the first realise of patch for multicast support in RTnet , This realise 
> support :
> * IGMP V2
> 
> I have only adapt the NIC drivers for :
> *RT_8139too  : Tested
> *RT_eepro100  : Not Tested
> 
> -HOW TO USE IT ;
>      1- Apply the patch to rtnet : (0.8.1 - 0.8.2 - 0.8.3)
>      2- Patch the NIC driver 
>      3- Execute the autogen.sh scritp to generate a new configure file. (a new    
> config option will added "--enable-multicast" )
>      4-execute configure   "./configure --with-rtai=<RTAI-DIR> 
> --enable-multicast "
> 
> Now in your application if you want to receive multicast packets  you must use 
> setsockopt  " RT_IP_ADD_MEMBERSHIP " , to stop the reception of multicast 
> packet you can use "RT_IP_DROP_MEMBERSHIP"
> 
> Don't forget when sending multicast packet to specify the local IP adress,  
> don't use INADDR_ANY (Only way I've fount to locate the device) .
> 
> for more detail about use of multicast in RTNET please see the sample attached 
> to this mail.
> 
> I hope if any body can test this patch ,and if you have any idea to improve 
> it. 
> 
> Im working now on a new realize of this patch , I will  add :
> * the possiblity to modify the TLL value( new IOCTL in the socketopt).
> * IGMP V1 Support.
> * A random response to the query request (IGMP  V1 & V2).
> 
> 

Great! Thanks for the patch, it looks very good. So far I only 
cross-read parts of it. Let's see if you got the implications of this 
multicast patch correctly:

  o Joining or leaving a multicast group can be performed from
    non-real-time context. Are those IOCTLs (or should they once become
    socket options?) compatible with the linux multicast interface, or
    does that one work differently?

  o Routing is as simple as finding the NIC a socket is bound to via its
    source address.

  o It take a periodic rt-task to send some "keep-alive" igmp message
    every 500 ms with low priority (how long may this message be delayed
    until switches start to drop the membership?). Is this also required
    in case I'm connected to hubs or an unmanaged switches?

The patch is very unintrusive to the core, especially when 
CONFIG_RTNET_MULTICAST is not selected. Therefore, I will see if we can 
merge into SVN soon. But I have two tiny criticisms:

  o The handling of RT_IP_ADD_MEMBERSHIP and RT_IP_DROP_MEMBERSHIP should
    check for the correct context (non-RT), and it should be moved to the
    IP subsystem (rt_ip_ioctl or even rt_ip_setsockopt).

  o Please review your driver patches if changing multicast addresses
    does not clash with the real-time operation of the NIC. At least
    the multicast set funtion of the rt_8139 does not seem to use the
    correct locking functions yet and uses printks within critical
    sections (note that it has not been used in parallel with RT-parts of
    the driver so far). Let me know if you need some hints in this
    respect.

Thanks again,
Jan

[RTnet-developers] Patch for multicast support for RTnet

[amine <am...@an...>]

hi ,

Here the first realise of patch for multicast support in RTnet , This realise 
support :
* IGMP V2

I have only adapt the NIC drivers for :
*RT_8139too  : Tested
*RT_eepro100  : Not Tested

-HOW TO USE IT ;
     1- Apply the patch to rtnet : (0.8.1 - 0.8.2 - 0.8.3)
     2- Patch the NIC driver 
     3- Execute the autogen.sh scritp to generate a new configure file. (a new    
config option will added "--enable-multicast" )
     4-execute configure   "./configure --with-rtai=<RTAI-DIR> 
--enable-multicast "

Now in your application if you want to receive multicast packets  you must use 
setsockopt  " RT_IP_ADD_MEMBERSHIP " , to stop the reception of multicast 
packet you can use "RT_IP_DROP_MEMBERSHIP"

Don't forget when sending multicast packet to specify the local IP adress,  
don't use INADDR_ANY (Only way I've fount to locate the device) .

for more detail about use of multicast in RTNET please see the sample attached 
to this mail.

I hope if any body can test this patch ,and if you have any idea to improve 
it. 

Im working now on a new realize of this patch , I will  add :
* the possiblity to modify the TLL value( new IOCTL in the socketopt).
* IGMP V1 Support.
* A random response to the query request (IGMP  V1 & V2).



-- 
EL HEDADI Amine
R&D 
phone : 
Email : am...@an...