From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4A38A64E.6090804@domain.hid> Date: Wed, 17 Jun 2009 10:16:14 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <188636.66895.qm@domain.hid> <1245226197.1443.18.camel@domain.hid> In-Reply-To: <1245226197.1443.18.camel@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Native API rt_pipe_monitor() call can not be called from an RT Task in linux userspace ? List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Philippe Gerum Cc: xenomai@xenomai.org Philippe Gerum wrote: > On Tue, 2009-06-16 at 15:23 -0700, Guvenc Gulce wrote: >> Hello >> >> I have the following questions regarding the rt_pipe behavior in Xenomai. >> >> -> Why is not possible to use rt_pipe_monitor() Native API call from an userspace RT Task ? > > Because this API is aimed at providing help to drivers implementing the > kernel space endpoint of a pipe connection; the driver/module may then > make userland benefit from this in a way or another, but it is not the > primary intent. > > Additionally, the pipe monitors are based on function calls for > notification, which is a real issue in a dual kernel system, when the > caller is not the linux kernel, but the co-kernel. We would have to > reinstate the userland address space context as fast as possible just > for the time needed to run the handler, and we would have to do so from > a real-time context that could be utterly unsafe from the linux kernel > POV. > > There is another option we have been digging for some time to emulate > such kind of callouts using an asynchronous approach under the hood, > that would allow us to support real-time signals crossing address spaces > as well. But this is still on the drawing board. > >> -> What is the solution if async notifications in rt-pipe context are needed in userspace RT Tasks ? >> >> > > If you don't care about real-timeliness of the receiver (i.e. userland > does read() and not rt_pipe_read/receive()), then SIGIO is available, > but maybe this is not what you want if your receiver is actually a RT > task. Otherwise, you will have to resort to a server task reading the > pipe to emulate an asynchronous behavior out of a synchronous construct, > I'm afraid. > > 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. > >> >> -> Is there any plan to implement something similar to linux's epoll system call for the rt-pipes used >> in userspace RT tasks ? >> > > No plans yet, even if not objection to merge this either. Actually, we already have xnselect, which could be used to implement this. But we would have to implement a native interface using it, and modify the rt-pipes to plug into the xnselect API (this has already been done, but not merged into head). -- Gilles