Philippe Gerum wrote:
On Mon, 2011-02-21 at 21:26 +0100, varname wrote:
Philippe Gerum wrote:
On Mon, 2011-02-21 at 18:54 +0100, varname wrote:
trying to write a simple producer / consumer using message pipes in
the native API, this phrase from the documentation (found here [1])
confuses me:
"-EPIPE is returned if the associated special device is not yet open."
It's not so much the sentence itself, but more the fact that I'm not
getting that return value from rt_pipe_stream() when streaming bytes
to a RT_PIPE that hasn't had its "special device" opened in secondary
domain.
I've attached a modified trivial-periodic.c that demonstrates what I'm
seeing. Afaik there is nothing open(2)-ing the /dev/rtp9 in the
secondary domain. All writes succeed, up to about write 31 (*1024),
after which all writes return 0.
[..]
wrote: 1024, res: 1024
wrote: 1024, res: 948
wrote: 1024, res: 0
wrote: 1024, res: 0
[..]
Is the documentation incorrect, or am I misunderstanding something?
The doc is wrong (former implementation, 2.1.x series), the pipe
services do buffer real-time output until the special device is
eventually opened starting with Xenomai 2.2.x. Since you are using
rt_pipe_stream(), the output is directed to an internal buffer until
there is no more space there, which causes the final 0-byte returns.
So everything looks ok, except the doc.
ok, so there is actually no way to detect whether or not the special
device has been opened?
Nope.
As I understood from earlier mails on the list,
writes to a full pipe buffer just fail, correct?
From the -rt side, yes. From the nrt domain via /dev/rtp*, it blocks
until the output buffer drains, unless O_NONBLOCK was set on the fildes
(-EWOULDBLOCK).
Is there any way to flush a message pipe from a userspace task (as
opposed to a kernelspace one, where rt_pipe_flush is available)?
There is no official interface for this, but you can get this working
with:
#include <nucleus/pipe.h>
ioctl(fd, XNPIPEIOC_OFLUSH), flushes the output queue (rt -> nrt)
ioctl(fd, XNPIPEIOC_IFLUSH), flushes the input queue (nrt -> rt)
Ok. I hate to keep asking like this, but seeing as this is an ioctl with
a file descriptor parameter: this is not done from the primary domain
right? Perhaps my description was a bit ambiguous, but I with
'userspace' I meant a userspace Xenomai task in the primary domain. I
guess the rt_task could open(2) the Linux device and perform the ioctl,
but would be nice to not have to.
FYI: the RT_PIPE interface is deprecated and will go away in the 3.x
series (the upcoming 2.6.x series still has it though). It is officially
replaced by the RTIPC/XDDP protocol (same purpose, but via the
RTDM/socket interface):
http://www.xenomai.org/documentation/xenomai-head/html/api/group__rtipc.html#ggba01db17f4a2bfbc3db60dc172972a2528a488c3e7fc47dee4d5757f215f62e9
I'm not saying you should drop RT_PIPE for RTIPC immediately in 2.5.x, I
would wait for 2.6.x for this move. But you may want to keep this in
mind if long-term portability is a goal.
Thanks. I remember reading something about that in the kernel config.
I'll keep it in mind for when 2.6 is released. In this particular
project the transport's details are abstracted away, so adding one based
on RTIPC/XDDP shoulnd't be too hard.
thanks again
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
