[Xenomai-help] rt_pipe_stream: not getting EPIPE

[Xenomai-help] rt_pipe_stream: not getting EPIPE

[varname]

[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

All,

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?

Related info:
  Xenomai: 2.5.5.2
  Kernel: 2.6.32.26

[1] http://www.xenomai.org/documentation/trunk/html/api/group__pipe.html#gb4d85ecda7675a75611500070c28b22e

[-- Attachment #2: trivial-periodic.c --]
[-- Type: text/x-csrc, Size: 911 bytes --]

#include <signal.h>
#include <unistd.h>
#include <sys/mman.h>

#include <native/task.h>
#include <native/pipe.h>
#include <rtdk.h>


RT_TASK demo_task;


void demo(void *arg)
{
	rt_task_set_periodic(NULL, TM_NOW, 5e8);

	RT_PIPE pipe;
	int res = rt_pipe_create(&pipe, "some_name", 9, 0);
	if(res < 0)
	{
		rt_printf(strerror(-res));
		return;
	}

	const unsigned int bsize = 1024;
	unsigned char buf[bsize];

	while(1)
	{
		rt_task_wait_period(NULL);

		res = rt_pipe_stream(&pipe, &buf, bsize);
		rt_printf("wrote: %u, res: %d\n", bsize, res);

		rt_task_sleep(1e8);
	}
}

void catch_signal(int sig)
{
}

int main(int argc, char* argv[])
{
	signal(SIGTERM, catch_signal);
	signal(SIGINT, catch_signal);

	mlockall(MCL_CURRENT|MCL_FUTURE);

	rt_print_auto_init(1);
	rt_task_create(&demo_task, "trivial", 0, 99, 0);
	rt_task_start(&demo_task, &demo, NULL);

	pause();

	rt_task_delete(&demo_task);

	return 0;
}

Re: [Xenomai-help] rt_pipe_stream: not getting EPIPE

[varname]

varname wrote:
> Related info:
>   Xenomai: 2.5.5.2
>   Kernel: 2.6.32.26

Just realised I forgot some important bits:

  x86
  I-Pipe: 2.7-03

Re: [Xenomai-help] rt_pipe_stream: not getting EPIPE

[Philippe Gerum]

On Mon, 2011-02-21 at 18:54 +0100, varname wrote:
> All,
> 
> 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.

> 
> Related info:
>   Xenomai: 2.5.5.2
>   Kernel: 2.6.32.26
> 
> [1] http://www.xenomai.org/documentation/trunk/html/api/group__pipe.html#gb4d85ecda7675a75611500070c28b22e
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

-- 
Philippe.

Re: [Xenomai-help] rt_pipe_stream: not getting EPIPE

[varname]

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? As I understood from earlier mails on the list, 
writes to a full pipe buffer just fail, correct?

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)?


thanks for the swift reply

Re: [Xenomai-help] rt_pipe_stream: not getting EPIPE

[Philippe Gerum]

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)

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 for the swift reply
> 

-- 
Philippe.

Re: [Xenomai-help] rt_pipe_stream: not getting EPIPE

[varname]

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

Re: [Xenomai-help] rt_pipe_stream: not getting EPIPE

[Stefan Kisdaroczi]

Am Montag 21 Februar 2011, 21:33:53 schrieb varname:
> 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? 

as a workaround you could use for example a named semaphore to do the 
synchronisation on pipe creation. (only if both task are xenomai tasks):

receiver:
  rt_pipe_create()
  rt_sem_create( NAME )
  rt_pipe_read()

sender:
  rt_sem_bind( NAME )
  rt_pipe_create()
  rt_pipe_send()

If rt_sem_bind() succeeds, the receiver should have created the pipe...

Stefan

> > As I understood from earlier mails on the list,
> writes to a full pipe buffer just fail, correct?
> 
> 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)?
> 
> 
> thanks for the swift reply
> 
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

Re: [Xenomai-help] rt_pipe_stream: not getting EPIPE

[Philippe Gerum]

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.

Re: [Xenomai-help] rt_pipe_stream: not getting EPIPE

[Philippe Gerum]

On Mon, 2011-02-21 at 23:50 +0100, Philippe Gerum wrote:
> 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.

Or simply call rt_pipe_flush() from ksrc/native/pipe.c with the pipe
descriptor and mode, once decoded from the syscall actually.

> 
> > 
> > > 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.