Hi all Thanks for the replies so far. Maybe I should give some background info regarding my needs and why I have asked this question at the first place so that you guys may have some ideas how to solve such a situation in an elegant way by using the current APIs of Xenomai.
I am planning to develop a mechanism which allows me to use Linux Network Sockets(send/receive) from an RT Task running in linux userspace. (I am aware of the RTNet but I don't really need real timeliness and determinism on the wire.) What I need is that my RT Task in the userspace does not lose its real timeliness at any cost. My Understanding is that calling Linux APIs (e.g. socket(), bind() etc.) from RT Tasks disturb the real timeliness of the RT task. Is there something already developed to meet such a need in Xenomai context ? If not, what would be the best way to approach such a problem ? Here are few ideas I have : * RT Task(Userspace) <---Connnected with RT Pipes---> Linux Task(Userspace, does the socket API calls) The problem with this approach is that RT Pipe API is not fully available in userspace and ugly O(n) Algorithms should be used at some places. (Synchron/Serial pipe handling) * RT Task(Userspace) <---Connected with Posix System Calls--> RTDM (Kernel Space) <-- RT Pipes --> Some other Kernel Module(Kernel space, does the Socket API calls) I am not sure whether such an approach would work at all. Maybe RT Pipes are not necessary at all and RTDM can do the Linux Socket API calls, in other words, RTDM would wrap Socket API calls with some additional logic. Would such an approach disturb the real timeliness of the original caller RT Task? RT Task calls RTDM which then calls some linux stuff which may cause a switch to secondary domain ? There are also a lot of similar APIs in Native and Posix skins. Would it be correct to say that one of them can be randomly picked, if there aren't concerns of legacy code compatibility issues. They are somewhat confusing and it is not really clear which Skin in which case really makes sense. Native Skin has RT-Pipes and Queues and on the other hand Posix has only Queues. Can the Queues also be used for RT Task <--> Non-RT Task communication as in the case of RT Pipes ? Thanks in advance for the comments Guvenc ----- Original Message ---- From: Philippe Gerum <[email protected]> To: Gilles Chanteperdrix <[email protected]> Cc: [email protected] Sent: Thursday, June 18, 2009 12:41:53 AM Subject: Re: [Xenomai-help] Native API rt_pipe_monitor() call can not be called from an RT Task in linux userspace ? On Wed, 2009-06-17 at 12:30 +0200, Gilles Chanteperdrix wrote: > Peter Soetens wrote: > > On Wed, Jun 17, 2009 at 10:09, Philippe Gerum<[email protected]> wrote: > >> As you have probably understood already, building a full real-time to > >> real-time data path using pipes is not possible; this said, this is not > >> the purpose of this API anyway, which has been designed for real-time to > >> non-RT communication. > > > > I was hoping to use rt_pipe + select in real-time context to implement > > a data receiving server for real-time inter-process communication. Is > > this possible ? > > What would happen if the real-time clients open the pipes as rt_pipes > > and start sending > > data in ? What's the alternative to listen in real-time to many > > connections from > > a single thread ? > > Note that posix message queues already work for inter-process > communications, with support for select. Depending on your needs, this > may be sufficient: you will need Xenomai threads on both sides, but the > non real-time one may use the SCHED_OTHER policy. > > I was thinking, maybe we could map the xnpipe to a special flag in mq_open ? > Albeit the message pipes are most of the time used in datagram mode, it can also be used in byte stream mode, which would not fit the mq semantics that nicely (I'm a bit afraid of potential overhead as well). Actually, we do have a pivotal API we could use further, and this is RTDM. We could have a set of socket-based RTDM drivers that implement different RT communication domains for IPC, one emulating a real-time socketpair for local IPC as you mentioned for instance, another one would bear the message pipe semantics etc. RTDM already complements all other APIs, so there would be no need to extend those to get message pipes with select() support, and we could even go as far as deprecating the existing message pipe API from the native skin, at some point. Besides, all RTOS emulators we support work fine side-by-side with either the POSIX or native skins, which in turn do support the RTDM model. So basically, we write one IPC driver, it works for the whole set of APIs we have, without any change. Maybe it's time for ksrc/drivers/ipc or something? -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
