From: Philippe Gerum <rpm@xenomai.org>
To: Guvenc Gulce <gulceg@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] Native API rt_pipe_monitor() call can not be called from an RT Task in linux userspace ?
Date: Wed, 17 Jun 2009 10:09:57 +0200 [thread overview]
Message-ID: <1245226197.1443.18.camel@domain.hid> (raw)
In-Reply-To: <188636.66895.qm@domain.hid>
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.
> Thanks & Regards
>
> Guvenc
>
>
>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
next prev parent reply other threads:[~2009-06-17 8:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-16 22:23 [Xenomai-help] Native API rt_pipe_monitor() call can not be called from an RT Task in linux userspace ? Guvenc Gulce
2009-06-17 8:09 ` Philippe Gerum [this message]
2009-06-17 8:16 ` Gilles Chanteperdrix
2009-06-17 9:40 ` Peter Soetens
2009-06-17 9:50 ` Gilles Chanteperdrix
2009-06-17 10:30 ` Gilles Chanteperdrix
2009-06-17 12:13 ` Peter Soetens
2009-06-17 12:25 ` Gilles Chanteperdrix
2009-06-17 13:16 ` Peter Soetens
2009-06-17 22:41 ` Philippe Gerum
2009-06-18 17:20 ` Guvenc Gulce
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1245226197.1443.18.camel@domain.hid \
--to=rpm@xenomai.org \
--cc=gulceg@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.