On Mon, 2004-11-22 at 17:22, Jan Kiszka wrote: > Philippe Gerum wrote: > >> > >>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. >
Ack. > >>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. Indeed because this is a gray area, I chose the library form for fusion because I have lived an absolute nightmare maintaining the dual mode for RTAI 3.x. You have different behaviours to take into account depending on how the -g and -O switches are combined. IMHO, this invariably ends up in a confusing situation, even if the maintainer can do a lot to hide the gory details for that. But when this fails, users are trapped in braindamage 'undefined symbols errors' which are painful to track down. > > > > >> 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. > Ok, so this was a false move then. We can just add them back. > Jan -- Philippe. ------------------------------------------------------- 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
