Leopold Palomo-Avellaneda wrote: > Hi, > > now that I can play more with rtnet I have more doubts that I would like to > share to try to find the light in this dark path .... > > - first of all, it's convenient that I erase /dev/rtnet every time that I > unloaded rtnet?
Why erase (most distros will do that for you anyway on reboot)? Better consider adding an udev rule for this device. > > - I have found a correct route table playing with the times and the order. > For > example, this script shows a correct route table. This is normal? > > ----------------------------------------------------------------------- > #!/bin/sh > echo "Creating the device" > mknod /dev/rtnet c 10 240; > > echo "Loading rtnet module" > insmod /usr/local/rtnet/modules/rtnet.ko; > > echo "Loading rtipv4 module" > insmod /usr/local/rtnet/modules/rtipv4.ko; > > echo "Loading rtpacket module" > insmod /usr/local/rtnet/modules/rtpacket.ko; > > echo "Loading rt_loopback module" > insmod /usr/local/rtnet/modules/rt_loopback.ko; > > echo "Loading rt_e1000 driver" > insmod /usr/local/rtnet/modules/rt_e1000.ko; > > echo "Loading the capture interface module" > insmod /usr/local/rtnet/modules/rtcap.ko; > > echo "Configuring the loopback" > /usr/local/rtnet/sbin/rtifconfig rtlo up 127.0.0.1 > > echo "Configuring the rteth0 interface" > /usr/local/rtnet/sbin/rtifconfig rteth0 up 10.0.0.1 netmask 255.255.255.0; > > echo "Waiting 4 seconds ...." > sleep 4; > > echo "Configuring the rteth1 interface" > /usr/local/rtnet/sbin/rtifconfig rteth1 up 10.0.1.1 netmask 255.255.255.0; > > echo "Waiting 4 seconds ...." > sleep 4; > > echo "Attaching explicit to the rteth0 interface" > for((i=1;i<5;i++)); do > /usr/local/rtnet/sbin/rtroute add 10.0.0.$i 00:1b:21:05:0c:fc dev rteth0; First, it makes no sense to define a RT-route for .1 as this is the local IP address which has to be routed over rtlo - if you need local loopback at all. And then I don't understand why you need manual RT routes here, all pointing to the same MAC. Didn't soliciting the actual address not really work out? > echo "Attached 10.0.0.$i to rteth0" > done > > echo "Attaching explicit to the rteth1 interface" > for((i=1;i<5;i++)); do > /usr/local/rtnet/sbin/rtroute add 10.0.1.$i 00:1b:21:05:0c:b6 dev rteth1; > echo "Attached 10.0.1.$i to rteth1" > done > > echo "The final route table" > /usr/local/rtnet/sbin/rtroute > ------------------------------------------------------------- > > > - I was playing with rtnet some time ago but with rtai. I looked the > examples. > Now, I'm trying to play with xenomai, but I have found that the examples some > two folders: native and posix. The native use the rt**** calls but the posix > use a _normal_ net calls. Looking on the wiki, I have found this: > > TODO: explain differences of native rt_dev_xxx vs. POSIX service calls (with > Xenomai) > > could someone tell me something? Probably it's no the same, but this means > that in xenomai I can use normal net calls to use a rtnet interface in > realtime? 1) Independent of RTnet, Xenomai application can call into normal networking services of Linux. They just loose timing guarantees at that point. 2) The programming model of the POSIX skin allows you to use socket functions as if you are writing a normal Linux application. In case your calls address a service which RTnet provides (UDP or AF_PACKET) and RTnet is loaded, it will handle it for you under realtime constraints. Services unknown to RTnet are passed through to Linux, without timing guarantees. BTW, the same pattern works for AF_CAN. HTH, Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
