Paolo Mantegazza wrote: > [EMAIL PROTECTED] wrote: >> Hello everyone, currently I am working on a project involving a >> network validation >> tool/solution currently based on RTAI version 24.1.13 and RTnet >> version 0.7.0 on the 2.4.20 (rthal5 patched) kernel. >> >> What I am trying to do now is assess the possibility and effort >> involved to migrate the beforementioned solution to RTAI v3.3 with >> RTNET v0.9.2 on the 2.6 kernel. >> >> I can't go into full detail with the solution's source code but I can >> tell you that it exploits the RTNET & RTAI API to their full >> potential. This might be a major setback for me now because I have to >> investigate whether the code for the solution has to re-written again >> due to possible changes in the newest RTNET or RTAI API. >> I know that every solution/project has its unique characteristics, but >> I am only concerned on the use of the API part. Should I worry about >> incompatibilities in the code, and on what degree? >> >> Thanks to anyone who even bothered to read through my request! :) >> >> PS: I am not a lazy man, I have looked through the changelogs several >> times...I just need a second opinion. Doesn't everyone? ;) > > RTAI compatibility with older version has remained. I've had a > counterproof recentely when an industrial application migrated from > RTAI-24.1.11 to 3.3 with just a few minor problems. > > As for RTNET it is now based on its own application layer that is called > RTDM.
In fact, even 0.7 was based on some predecessor of RTDM, but that one came with RTnet while it is now part of the real-time Linux extension to open it to other users (=drivers) as well. > RTAI 3.3 does support it but there have been further improvment > found in MAGMA CVS. My tests on RTNET, basic ones, seem OK and there are > RTDM support test in RTAI showroom, including direct use of examples > developed by RTNET people and used unchanged (almost). Due to the fixes of RTDM since release 3.3 you must start with vulcano or magma CVS. Regarding RTnet's API: you should only be hit (potentially) by the replacement of RTNET_RTIOC_NONBLOCK with RTNET_RTIOC_TIMEOUT - really a minor change. And if you happen to find a regression (but I'm not aware of any ATM), feel free to report it on either (or both) of the involved lists. Jan
signature.asc
Description: OpenPGP digital signature
