Hello,
some significant changes have to be announced. The CVS contains now a widely revised user API.
DONT'T PANIC!
Most of the functions kept their semantics, it's still BSD/POSIX-like, of course. The naming scheme and the internal realisation have changed, some RTnet-specific features have moved. But before going into details, let me explain the motivation for this revision.
[Posted to rtai-dev as well]
For quite some time, I had the idea in mind to create a generic real-time driver model (=>RTDM) for Linux. Such a model shall help to standardise the driver development for RTAI in particular, but also real-time Linux in general. The respective management layer shall be (and the current RTAI implementation is) released under LGPL in order to avoid any theoretical trouble with proprietary applications, but also to allow binary-only drivers if they cannot be avoided (I'm not a fan of those, but I'm realistic as well). Further advantages are that, with a well-defined driver model and common entry functions, hardware exchanges without modifying the applications will become much easier, and it will be possible to load different drivers with an identical interface at the same time. Finally, I also have a personal interest in such a standardisation :), as my research becomes easier when I can build on a small driver interface instead of the current tangled mass of driver libraries.
Currently, the RTDM concept focuses on a sound interface to the user by providing POSIX IO functions (open/read/write etc.), a socket interface (socket/recvmsg/sendmsg etc.), and common calls (close/ioctl). Less frequently used functions like setsockopt, bind, etc. are mapped by inline wrappers on IOCTLs. The interface is available both in kernel and user mode, it uses a file descriptor interface, and it detects and reports the caller's context to the driver (real-time or not, user or kernel mode). The naming scheme is just like the POSIX wrappers of RTAI: standard name + _rt suffix, i.e. open_rt, ioctl_rt, etc. This also avoids potential collisions with existing RTAI code (AIO library or RPC functions).
Drivers or protocols can register with the RTDM layer to offer their services. Depending on the device class, certain features like specific IOCTLs have to be provided. That shall be defined in device profiles, e.g. one for serial devices, one for each fieldbus (CAN, Interbus, Profibus, etc.), one for a real-time UDP protocol (RTnet is an instantiation of it), and so forth. I think defining those profiles should be feasible within such a strong community like RTAI has. What is yet widely missing are concepts for device class specific sub-layers, like a CAN hardware abstraction layer, in order to ease new hardware inclusion. RTnet's NIC layer is another example which is even already existing.
[End of rtai-dev post]
So, RTnet has become a test stand for this concept and its first implementation. And everything seems to work as good as before. There are even some improvements which come along with this reconstruction. A lot of race conditions have been removed from code which modifies socket properties like source/destination IP/port, callback function/argument, etc. The TDMA interface for retrieving the global time stamp offset and for synchronising on the Start of Frame packet has become a RTDM device, thus it is now also available for user mode applications.
As threatened, there are some changes visible to the applications:
o new naming scheme (e.g. rt_recvmsg and rt_socket_recvmsg became recvmsg_rt). But if you define USE_RT_XXX_WRAPPER or USE_RT_SOCKET_XXX_WRAPPER, respectively, before including rtnet.h, you will be able to use the old naming scheme as well. o revised TDMA interface o RTnet-specific socket options (RT_SO_xxx) have become IOCTLs (RTNET_IOCTL_xxx) o rt_socket_callback is dropped, use ioctl_rt with RTNET_IOCTL_CALLBACK to set a callback handler (kernel mode only)
RTnet will come with an implementation of the RTDM layer for RTAI 24.x and 3.x. You can find the code in the rtai_rtdm directory. It is automatically build together with RTnet, but you can switch it off with --disable-enclosed-rtdm during the configuration phase (in case an RTDM module becomes part of RTAI someday). The module rtai_rtdm.o is NOT automatically loaded by the rtnet script, please adapt your RTAI loader scripts appropriately.
In order to encourage intensive testing of all these changes and new features (don't forget the routing table revision and the additional tools which were recently announced), we will package a 0.7.0-test1 version soon and will provide it for download on the RTnet page.
Ok, I hope I didn't forget anything.
Jan
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
RTnet-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/rtnet-users
