Hi Philippe,
I moved this thread to our developers list as we need to go into some details now.
... This was pretty straightforward. The only thing which might require some more work is about the use of the rtos_time_t, since the non-scalar type makes things more complex, or at least less natural. I did not put any accessor to the .val member but rather use it directly for now and left FIXMEs, leaving it to your final decision.
Actually, there were some typical RTIME vs. RTIME mixups - that's why I introduced the non-scalar type for timer ticks. This bites you when you use it the wrong way around. :)
Otherwise, there have been two other points I tried to deal carefully with, namely:
o the proper use of rtos_event_t, rtos_event_sem_t, or rtos_res_lock_t since it makes a difference for fusion which differentiates those, providing plain counting semaphores and mutexes with priority inheritance.
There was only a bug in the netshm example, mem_lock should be a rtos_res_lock_t. I hope this acquiring of the lock in task A, waking task B with some semaphore, and releasing the lock there will not cause any trouble with fusion, may it?
o the proper sequence of instructions using rtos_task_init()+rtos_task_resume() or rtos_task_init_periodic(), so that tasks are started in the same order under fusion. I think that like the above point, this one should be reviewed and checked against the original implementation in case of problems.
I had to introduce rtos_task_init_suspended and rtos_task_resume for netshm. However, the typical scenario in RTnet remains atomic init+resume.
There are two points remaining on my list:
o I think it makes more sense to leave rtai_rtdm really RTAI-specific and do not go the rtnet_sys.h way. Especially when it comes to the usermode interface, there will be no common abstraction anymore (beyond RTAI). RTDM should be rather seen as a part of the RTOS distribution, delivering it with RTnet should only be a kludge - at least on the long term. However, using the configure results for generating the fusion-specific parts for the RTnet-bundled version still makes sense. Or will a port of the LXRT interface change RTDM more substantially to raise the need for a separate code base?
o Marc is busy, so I cannot ask our expert first: Why did you patched all AC_HELP_STRINGs away in your configure.ac? Will they become obsolete soon?
Jan
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
RTnet-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/rtnet-developers
