M. Koehrer wrote: > Hi Jan, > >>>> I do not know of any activities, but it should not be a big effort to >>>> get RTnet ported over RTDM-native. As I see it, mainly the build system >>>> of RTnet needs adaption. >>>> >>> thanks for your response. That sounds very good. >>> I can remember, that a long while ago, the interrupt handling was not >> realized yet with rtdm-native >>> which is necessary to get rtnet up and running. >>> Is this implemented now? >> I'm not sure what you mean. RTDM-native has been tested with >> RT-Socket-CAN, which uses interrupts, of course. >> >> While reading my old README >> >> http://svn.gna.org/viewcvs/xenomai/branches/rtdm-native/README.rtdm-native?r >> ev=2386&view=auto >> >> I now remember some more quirks, especially with tasks termination, >> which might be problematic with RTnet. Maybe a RTDM port over >> Xenomai-Solo would be more straight forward, but that's another project.
RTDM native will become the (probably only) kernel component in the Xenomai/Solo project, thus there is no difference here. >> >> Wolfgang. >> > are there any plans to extend the rtnet build system to support rtdm-native > or (in future) Xenomai-Solo? No activities are known to me. But patches are always welcome. (Adopting the build system as a first step should be straightforward.) > Do you have any idea how to solve the issues Wolfgang has mentioned? It might be a good idea to rethink the task usage of RTnet and potential mappings on different mechanisms. For example, I would try to get rid of the stack manager (RX) task in RTnet and rather let the user (the high-layer protocols or the application) decide in which context to handle incoming data. Dispatching should be fast enough to run in IRQ context, maybe with some additional tweaking. Tasks--, latency--. Also the output task of the TDMA discipline is worth a look if we may not better use the new rtdm_timer API for this. Tasks--, maybe also latency--. Then there is the RTcfg layer. Its timed task along with this whole stack should rather be moved into user space. Tasks--. Finally we have the rtnetproxy and the nomac demo descipline. I guess conversions are not feasible here, but maybe we can avoid that those users depend on rtdm_task API properties that are not mappable on plain Linux. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
