On Mon, 2011-02-21 at 22:21 +0100, varname wrote: > 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. >
Yes, that hack would entail a switch to non-rt mode in that case. rt_pipe_flush() is missing from ksrc/skins/native/syscall.c. Maybe you could get some inspiration from the way __rt_pipe_delete() is implemented there, for retrieving the pipe descriptor pointer from the syscall args, and have your new __rt_pipe_flush() request mimic what xnpipe_ioctl() does for the above commands. > > > 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 > -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
