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?
I'm afraid it would; this is why I did not put a rtos_res_lock_t there since it is backed by a RT_MUTEX object. Since a mutex exhibits an ownership property for handling the prio inheritance, attempting to unlock it over a task which did not acquire it in the first place would fail.
Ok, I split the locking up into two parts. It's saner, but I hope this does not break anything else - had no time to test.
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?
I don't think so. Adding the RTNet syscall interface for fusion won't change things that much wrt LXRT for the kernel side. On the user-space side, I tend to favour an interface library instead of inlines for emitting syscalls, but there is nothing preventing the latter to be implemented if you prefer it that way.
I have no problem with a library. But I'm still unsure when a library is more efficient than inline variants. I would be probably best to couple the mode to RTAI configuration in this respect.
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?
AFAIK, they have been obsoleted by AS_HELP_STRING() since Autoconf 2.58. I've removed them because it works with 2.59 but if you really want to keep pretty help strings, I guess that AS_HELP_STRING() is the way to go now.
Well, I meant AS_HELP_STRING, and RTnet only contains these macros. I remembered Marc switching them some time ago, and that's what made me wonder about your patch.
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
