Hi, Jan,
I just committed the firewire code to the branch, so now you can play around
with it-:).
Very good, but we unfortunately do not yet have any hardware for it. Will see how soon I can change this...
The order to load modules: rt_ieee1394.o rtos_tasklet_scheduler.o
rt_ohci1394.o and rt_eth1394.o
Please tell me if you find any bug or bad coding.
Just a few comments from my first view on the source code and the first attempt to compile it:
o I get some warnings (no errors!) during compiling against RTAI 3.1 / Kernel 2.4.28 using gcc 3.3.4 (SuSE). If you aren't already aware of it, I can post them.
o rtos_tasklet_scheduler.c: You only use the tasklet spinlock on removal, but not on insertion. This is no practical problem on UP boxes (I guess rtos_tasklet_schedule runs in IRQ context), but it will fail on SMP. Use rtos_spin_lock/unlock if IRQs are already switched off.
o For 2.6 support, we will need to restructure your firewire directory. Every module will need its own folder to let the 2.6 kbuild process work. The question is anyway, if anything except rt_eth1394.o may better be put in some stack subdirectories on the long term. But that also involves the question which public driver model you may already have in mind for raw-1394 access.
So far, more may follow. ;)
Jan
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ RTnet-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-developers
