Hi Mathias, M. Koehrer wrote: > Hi Jan, > >> RTDM native will become the (probably only) kernel component in the >> Xenomai/Solo project, thus there is no difference here. > If I get it right, Xenomai/Solo is a pure Userspace library that allows to > use the Xenomai API on top > of Standard Linux or Preempt/RT.
Yes, so far Xenomai/Solo is fine with staying in user space to emulated the supported RTOS APIs (Xenomai's Native API is not yet supported IIRC). But when it comes to porting drivers between single (/Solo) and multi kernels (/Duo, likely the Xenomai 2.x successor), you will not be able to do much (efficiently) in user-land. This is where the RTDM-native package comes into play as a logical extension of Xenomai/Solo's feature set. BTW, just check with the device classes UIO is able to cover. And also keep in mind that even that approach will never be pure user space. > The obvious question is now: Why not making rtnet an user space library as > well? Because it is a protocol stack that may serve both more simple single-user scenarios like yours as well as multi-user/multi-process setups. > This could solve the issue that special rtnet network drivers are necessary. Nope, you basically move the code around, making certain tasks simpler, granted, but also restricting its usability at the same time. > I while go, I looked closer at preempt/RT and I did not find a solution for > using real time IP (UDP) here as there > is one central network receive task that does the job and does not prioritize > the network traffic (all incoming frames are > handled equal - no matter if they are "slow" TCP or "real time" UDP). > One suitable way out here could be to provide a second, receive task that > does the job for real time ethernet frames. > This is the same as the central receive task (stack manager) in rtnet today. > Any why not "inserting" a turnout into the Linux kernel that redirects frames > (e.g. from some network adapters or on > what ever metric) to the "realtime" receive routine, all other frames are > given to the standard network stack. > And why not running this routine (mainly) in user space? Because this is fairly inefficient once there are >1 processes (==address spaces) interested in using it. > For me rtnet is the perfect candidate to do exactly this! Nothing is impossible, but my feeling is that you should look into some more design aspects first. > We are currently using Xenomai/Rtnet on the latest PCs, i.e. we have to use a > fairly modern kernel, the latest network drivers (to support the brand new > onboard NICs of the mainboards), ... > And - of course - Xenomai and rtnet cannot release a version as often as the > linux kernel does. > That means, there is always a gap which means some ugly backporting of > network drivers has to be done... Did I missed some patch of yours to push I-pipe or RTnet to a yet-unsupported-but-desperately-needed new kernel release? :-> Often the subjective dependency is stronger than the actual one. If there are hard requirements, you are welcome to discuss them with us. > Using an approach that does all this using Linux and the PREEMPT/RT patch > could make life much easier here. ...once merged. Right now it is on the same support level like Xenomai (in this case: no official 2.6.25 patch). And keep in mind that user-space hosted drivers will not remove the need to update/extend them for new hardware. The only way around this additional work is making mainline Ethernet drivers with its core environment RT-capable, thus maintain such a property in-tree. If you have concrete ideas in this direction, you'll be welcome! > However - as mentioned before - some network messages have to be processed in > real time, others not as > the linux network stack does not care about real time networking. And you have to deal with buffer management. All a saw about this for mainline were the swap-over-nfs patches, but that series only comes with a single, swapping-dedicated deterministic buffer pool. > > Best regards and thanks for all feedback on this comment! > > > Mathias BTW, maybe you want to have a look at the Qualcomm way of RT on multicores. That was announced on LKML last month, check for the cpu isolation discussions. It is currently only visible via those patches and libe1000 (on sourceforge, IIRC). A user space driver, true, but still requires - a kernel stub - separate maintenance The general idea of this ultra low-latency user-land RT is nice, but we are still waiting for more details (==code) to fully assess its strengths and limitations. Maybe you can use it to make your ideas for future (user-space) RT networking stacks more concrete. Even better were, of course, code contributions in this direction, as not many people here (and elsewhere) are twiddling thumbs the whole day... ;) 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
