Q: What are the differences in functionality between an rtai and an adeos enabled kernel?
A: Adeos provides services to share critical hw resources (and some low-level sw ones too), between Linux and RTAI, so that RTAI always has priority over Linux when it comes to handle them (e.g. IRQ flow). It also provides some additional features (like inter-domain Adeos mutexes), but RTAI does not use them now.
The RTHAL patch (-rthalXg) goes hand in hand with arch/i386/rtai.c, i.e. both forming the original "HAL".
The Adeos patch (-adeos) is independent, exporting services used by arch/i386/arti.c, i.e. the Adeos-based Real-Time Interface. The latter interface is a rewrite of rtai.c implementing the same services, but based on the Adeos API instead of the RTHAL hooks.
arti.c has been designed to be compatible with rtai.c at the interface level.
PS: For more information, there is an on-line description of the Adeos API here: http://www.nongnu.org/adeos/doc/api/globals.html
Q: I am having problems enabling the 'uses_fpu' flag for task_init(). When I do so, my system crashes.
A: Check what happens compiling the kernel for K6 CPUs.
Q: When using memcpy and then floating point, the machine crashes
A: The problem is with memcpy using MMX or 3DNow extensions which interfere with the floating point unit. Use __memcpy instead of the regular memcpy to avoid using architecture specific optimisations. If you do it like that, your FP stuff will work afterwards:-)
(lxrt/simd is an examples that uses SIMD support)
A: The stack size defined in LXRT is just for the buddy server supporting RTAI services. So it can be safely assigned a value that, pathological interrupts floods apart, is more than enough to execute any RTAI function. In kernel space the stack size depends on what the user specific function/task has to do. So there is no way of assigning a safe default and it must be under user responsability completely.
Such a doubt does not exist with NEWLXRT, where stack_size is not used because there is no buddy and rt_task_init just extends the Linux task_struct with a pointer to the RT_TASK structure needed to support RTAI services.
A: No. As an example consider udelay() which indirectly accesses the "current" Linux task context to get some calibration information it needs about the CPU speed. The problem is: you have _no_ "current" Linux task when running on behalf of a real-time task (*) and dereferencing the symbol "current" (as defined in linux/asm/current.h) is invalid in this context. This is a recurrent problem that happens when using context-sensitive Linux kernel code on behalf of RTAI tasks. (*) The basic reason is that "current" (i.e. the pointer to the control block of the Linux task which is supposedly running at the time you ask for it) is ingeniously computed from the active stack pointer's value (i.e. %esp). This is possible because each Linux (x86) task control block is laid in the first 8k of any given task's stack. But RTAI tasks created by the UP sched have their own stack space, therefore in the first 8k of a RT stack you'll find, well, nothing that can be seen as a Linux task control block, but probably many reasons for your box to go sky high if you attempt to refer to it as such...
A: Yes and No. A kernel module can call a function defined in another kernel module and insmod will not allow you to insert a module that refers to another module.
AFAIK, two or more modules cannot have a circular dependency on each other.
A: Yes, you have to release the timer when exiting the real-time module which attached it. If you started the timer using start_rt_timer(), you should stop it using stop_rt_timer(), which calls rt_free_timer() in turn. IOW, rt_free_timer() is a generic HAL level routine which is used by the RTAI scheduler to hook the timer IRQ to its internal tick handler. Periodic/oneshot task scheduling is then handled from the latter. Conversely, HAL's rt_request_timer() is internally used by start_rt_timer() to initialize the periodic timer.
rt_task_delete() does not deal with anything else than unregistering the given task from the scheduler.
init_module => start_rt_timer() cleanup_module => stop_rt_timer() + foreach(task) rt_task_delete(task)
the above is a safe bet. Missing one of the cleanup actions listed is a usual suspect for kernel panics upon module unload with RTAI.
A: Well, exactly what you seem to suspect: the other modules would lose their heartbeat. AFAIK, we currently have no safety belt like refcounting the timer users or such.
A: One answer would be to use the RTAI long long math routines llimd() and friends.
See <rtai-root>/include/asm/rtai-24.h and many examples that use it.
A2: I use something like this in my Makefile:
ar x `gcc -print-libgcc-file-name` _moddi3.oS ld -m elf_i386 -r -o modulname.o $(OBJECTS) _moddi3.oSshould work for divdi3, too.