A Dijous 22 Novembre 2007, Jan Kiszka va escriure: > 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.
first because I don't know how to do it. Also, I have I device (/dev/rtnet) for all the interfaces, no? I mean, I don't have /dev/rtnet0 --> rteth0 /dev/rtnet1 --> rteth1 /dev/rtnet2 --> rteth2 with _only_ /dev/rtnet that's all. > > - 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? [....] > > > > 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? yes, you are right it make no sense but if i don't do that, I got: The final route table Host Routing Table Hash Destination HW Address Device 00 0.0.0.0 00:00:00:00:00:00 rtlo 01 10.0.1.1 00:00:00:00:00:00 rtlo 01 10.0.0.1 00:00:00:00:00:00 rtlo 01 127.0.0.1 00:00:00:00:00:00 rtlo 02 10.0.1.2 00:1B:21:05:0C:B6 rteth1 02 10.0.0.2 00:1B:21:05:0C:FC rteth0 03 10.0.1.3 00:1B:21:05:0C:B6 rteth1 03 10.0.0.3 00:1B:21:05:0C:FC rteth0 04 10.0.1.4 00:1B:21:05:0C:B6 rteth1 04 10.0.0.4 00:1B:21:05:0C:FC rteth0 3F 10.0.1.255 FF:FF:FF:FF:FF:FF rteth1 3F 10.0.0.255 FF:FF:FF:FF:FF:FF rteth0 and doing it, I got: The final route table Host Routing Table Hash Destination HW Address Device 00 0.0.0.0 00:00:00:00:00:00 rtlo 01 10.0.1.1 00:1B:21:05:0C:B6 rteth1 01 10.0.0.1 00:1B:21:05:0C:FC rteth0 01 127.0.0.1 00:00:00:00:00:00 rtlo 02 10.0.1.2 00:1B:21:05:0C:B6 rteth1 02 10.0.0.2 00:1B:21:05:0C:FC rteth0 03 10.0.1.3 00:1B:21:05:0C:B6 rteth1 03 10.0.0.3 00:1B:21:05:0C:FC rteth0 04 10.0.1.4 00:1B:21:05:0C:B6 rteth1 04 10.0.0.4 00:1B:21:05:0C:FC rteth0 3F 10.0.1.255 FF:FF:FF:FF:FF:FF rteth1 3F 10.0.0.255 FF:FF:FF:FF:FF:FF rteth0 look that the 10.0.x.1 goes to rtlo or rtethx assigning it with the route or not. I _must_ assign it specific because if not I got a lot of problems. My Stäubli controller doesn't like the rtnet/network card/xenomai/ whatever and I have to do some heuristic method (trial and error) to make it work (a simple ping can work or not if I boot the controller with the crosscable plug or unplug :-( ) [.....] > > > > 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. ok > 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. good .... this piece of text should be added to the wiki. I will be very clarify ... Regards, Leo ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-users
