On Fri, Apr 07, 2000 at 02:03:24PM -0700, Willem Atsma wrote:
Hi,
I wrote a driver and now I want to addapt it for RTLinux. Can anyone think of
reasons why I couldn't write a header file with macros to replace normal linux
calls with the appropriate rtl ones? Has anyone done this?
Willem
Drivers are usually designed in a 2 or 3 layer model, with the bottom
layer (closest to hardware) being mostly OS independent, and depending
mostly on the middle layer for its functionality. Linux drivers usually
follow this model, especially the network drivers.
There are 2 approaches to converting such drivers to real-time. One
is to make the low-level drivers _completely_ real-time and non-real-time
safe, and have the middle layer take care of the details of how
RTLinux/RTAI/Linux work differently. This is the approach I've taken
with comedi, mainly because I control the middle layer.
Another approach is to develop a second, compatible middle layer,
especially for real-time. This way, you can easily #define low-level
drivers to be real-time, non-real-time, or dual, simply by changing
compilation flags. This usually involves changing the names of the
important functions from func() to RT_func(), and then using
#ifdef DRIVER_RT
#define RT_func() rt_func()
#endif
#ifdef DRIVER_NON_RT
#define RT_func() func()
#endif
#ifdef DRIVER_DUAL
#define RT_func() (some_flag?rt_func():func())
#endif
That version is readable/understandable, but the following is easier to
maintain for many functions:
#ifdef DRIVER_RT
#define FLAG 1
#endif
#ifdef DRIVER_NON_RT
#define FLAG 0
#endif
#ifdef DRIVER_DUAL
#define FLAG some_flag
#endif
#define RT_func() (FLAG?rt_func():func())
Naturally, this approach requires that you have the same prototypes for
both rt_func() and func(), which is not the case for most functions that
you may want to use. One such example is request_irq() and its
equivalents in RTLinux and RTAI. The main benefit of this approach is
that you are able to use the same binary module for both real-time and
non-real-time, makeing testing easier.
I've had sucess with both approaches, although the latter is simpler
for porting existing code. Since you wrote the driver, I'd suggest
the first approach, since you are in charge of all the source.
If you driver doesn't follow a layered model, now would be a good time
to fix it.
dave...
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
