[Xenomai-help] inscrutable pipes

[Xenomai-help] inscrutable pipes

[ckreider]

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

Proud though I am, it is time to ask for help.  I have used pipes  
with RTLinux but want to use Xenomai this time.  I can't get pipes  
working.

(as an aside, I saw on here where if you do make install, it will  
create the necessary /dev/rtp* entries.  I work on a development host  
and do not compile on the target, so I do not run make install.  I  
finally found the mknod magic in a message on this list)

I am using Xenomai 2.2.1 with a 2.6.17.8 kernel.

I finally took Captain's example and added the missing function  
parameters, but it did not work.  Then I tried an example from a  
message here, which appears to be derived from Captain's example.   
Again, I had to add missing function parameters, and again it did not  
work.  I compared the examples to  ksrc/skins/native/snippets/pipe.c,  
and they look correct, except that the snippet is missing some  
function parameters also.

First the results:

try1:
insmod pipe.ko, ./user

kernel: rt_pipe_alloc starting
kernel: rt_pipe_alloc done - no errors
kernel: rt_pipe_send starting
kernel: rt_pipe_send done - no errors
kernel: rt_pipe_receive starting
kernel: INIT DONE - no errors

"user" is sleeping in read

try2:
insmod pipe.ko, cat /dev/rtp0

kernel: rt_pipe_alloc starting
kernel: rt_pipe_alloc done - no errors
kernel: rt_pipe_send starting
kernel: rt_pipe_send done - no errors
kernel: rt_pipe_receive starting
kernel: INIT DONE - no errors

cat hangs waiting for input

try3:
insmod pipe.ko, echo "World" >/dev/rtp0

kernel: rt_pipe_alloc starting
kernel: rt_pipe_alloc done - no errors
kernel: rt_pipe_send starting
kernel: rt_pipe_send done - no errors
kernel: rt_pipe_receive starting
kernel: INIT DONE - no errors
kernel: received msg> World
kernel: , size=6
kernel: rt_pipe_receive done

Obviously I got the right major/minor for /dev/rtp* as the rt task  
reads my echo.  Neither "user" or "cat" read anything from the rt task.

The code:

==== user.c ====
#include <sys/types.h>
#include <fcntl.h>
#include <string.h>
#include <stdio.h>
#include <native/pipe.h>

#define PIPE_MINOR 0

int pipe_fd;

int main (int argc, char *argv[])
         {
         char devname[32], buf[32];
         sprintf(devname, "/dev/rtp%d", PIPE_MINOR);
         pipe_fd = open(devname, O_RDWR);

         if (pipe_fd < 0)
                 {
                 printf("cannot open pipe %s\n", devname);
                 exit(1);
                 }

         read(pipe_fd, buf, sizeof(buf));
         printf("read from pipe: %s\n", buf);
         read(pipe_fd, buf, sizeof(buf));
         printf("read from pipe: %s\n", buf);

         write(pipe_fd, "World", sizeof("World"));
         printf("written string 'World' - see kernel log\n");

         close(pipe_fd);
         }


==== pipe.c ====
#include <linux/module.h>
#include <native/task.h>
#include <native/pipe.h>

#define PIPE_MINOR 0

#define TASK_PRIO  2               /* Highest RT priority */
#define TASK_MODE  T_FPU|T_CPU(0)  /* Uses FPU, bound to CPU #0 */
#define TASK_STKSZ 4096            /* Stack size (in bytes) */

RT_TASK task_desc;
RT_PIPE pipe_desc;

void task_body (void *cookie)
         {
         RT_PIPE_MSG * msgout, *msgin;
         int len = sizeof("HELLO");
         printk("rt_pipe_alloc starting\n");
         msgout = rt_pipe_alloc(&pipe_desc, len);
         if (msgout)
                 {
                 printk("rt_pipe_alloc done - no errors\n");
                 strcpy(P_MSGPTR(msgout), "HELLO");
                 printk("rt_pipe_send starting\n");
                 if (rt_pipe_send(&pipe_desc, msgout, len, 0) != len)
                         {
                         rt_pipe_free(&pipe_desc, msgout);
                         }
                 printk("rt_pipe_send done - no errors\n");
                 printk("rt_pipe_receive starting\n");
                 rt_pipe_receive(&pipe_desc, &msgin, TM_INFINITE);
                 printk("received msg> %s, size=%d\n", P_MSGPTR 
(msgin), P_MSGSIZE
                         (msgin));
                 printk("rt_pipe_receive done\n");
                 rt_pipe_free(&pipe_desc, msgin);
                 }
         else
                 {
                 printk("ERROR: rt_pipe_alloc\n");
                 }
         }

int __init init_module (void)
         {
         int err;
         err = rt_pipe_create(&pipe_desc, "pipetest", PIPE_MINOR, 0);
         if (!err)
                 {
                 err = rt_task_create(&task_desc, "MyTaskName",  
TASK_STKSZ,
                         TASK_PRIO, TASK_MODE);
                 if (!err)
                         {
                         rt_task_start(&task_desc, &task_body, NULL);
                         }
                 else
                         {
                         printk("ERROR: cannot create task\n");
                         return 0;
                         }
                 }
         else
                 {
                 printk("ERROR: cannot create pipe\n");
                 return 0;
                 }
         printk("INIT DONE - no errors\n");
         return 0;
         }

void __exit cleanup_module (void) {
     rt_pipe_delete(&pipe_desc);
     rt_task_delete(&task_desc);
     printk("CLEANUP DONE\n");
}

MODULE_LICENSE("GPL");



---
Carl Kreider
ckreider@domain.hid




[-- Attachment #2: Type: text/html, Size: 9302 bytes --]

Re: [Xenomai-help] inscrutable pipes

[Gilles Chanteperdrix]

ckreider wrote:
 > Proud though I am, it is time to ask for help.  I have used pipes  
 > with RTLinux but want to use Xenomai this time.  I can't get pipes  
 > working.
 > 
 > (as an aside, I saw on here where if you do make install, it will  
 > create the necessary /dev/rtp* entries.  I work on a development host  
 > and do not compile on the target, so I do not run make install.  I  
 > finally found the mknod magic in a message on this list)

I work on a development host and do not compile on the target, but I use
make install: I simply set the DESTDIR variable so that the files are
installed in a temporary directory that I can then share by NFS, rsync
on the target, use to create an initrd or filesystem image, or anything
else. This is much simpler than using mknod.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] inscrutable pipes

[Philippe Gerum]

On Thu, 2006-09-14 at 12:06 -0400, ckreider wrote:
> Proud though I am, it is time to ask for help.  I have used pipes with
> RTLinux but want to use Xenomai this time.  I can't get pipes working.
> 
> 
> (as an aside, I saw on here where if you do make install, it will
> create the necessary /dev/rtp* entries.  I work on a development host
> and do not compile on the target, so I do not run make install.  I
> finally found the mknod magic in a message on this list)
> 
> 
> I am using Xenomai 2.2.1 with a 2.6.17.8 kernel.
> 

The message pipe support has been refactored recently to behave like
classic FIFOs when accessed through the /dev/rtp* interface. All changes
have been committed to our repos, and should be obtained from there
until we roll out v2.2.3.

You can get the code through SVN at this URL:
http://svn.gna.org/viewcvs/xenomai/branches/v2.2.x/

Could you try it, and let us know if it solves the issue you raised?
TIA,

-- 
Philippe.

Re: [Xenomai-help] inscrutable pipes

[Gilles Chanteperdrix]

ckreider wrote:
 > That method is not very fine grained though.  You really don't want / 
 > usr/xenomai/share/doc/xenomai*, /usr/xenomai/man*, or /usr/xenomai/ 
 > include on the target and you really want /usr/xenomai on the  
 > development host.  But it does keep /dev and /lib/modules from  
 > getting polluted.  I think it just takes a soft link from /usr/ 
 > xenomai and selective gathering from DESTDIR for the target and it is  
 > pretty slick.  Thanks again.

The answer to this question should be to use a different value for
--prefix and --exec-prefix. But for this to work correctly, we should
install the testsuite under $exec_prefix.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] inscrutable pipes

[ckreider]

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


>>>
>>> Could you try it, and let us know if it solves the issue you raised?
>>
>> Yes, the issues are solved using Xenomi-2.2.x (gotten via svn) and
>> linux-2.6.17.13
>
> Ok, thanks.

I think I will expand on this because Xenomai coders are on this list.

We have two product lines that have been made for several years with  
custom hardware and proprietary RTOS.  We decided to migrate these to  
COTS hardware and Linux.  Conventional wisdom, right?  The other line  
migrated first.  There was pain, but not unbearable.  We used RTLinux  
because we needed something that could sample the A/D card at  
predictable intervals and it was what was available at the time.  I  
recently embarked on the conversion of my line and ran into a big  
problem.  My A/D card controls the timing, so I shouldn't need and  
RTOS.  I have a serial stream of 20 byte packets at 60 hz, but Linux  
should handle that, right?  Well, if I had Mot serial chips that did  
hardware handshake, it would be OK, but COTS hardware has 16550s  
which require and interrupt to drop the handshake line(s).  If Linux  
it too busy to service an interrupt for a full receive fifo, how is  
it going to handle the handshake?  It can't.  So I was dropping bytes  
every so often.  Linux didn't have to mask the interrupt for long,  
just a fifo full at 38400. So it wsa RTOS time.  I picked Xenomai  
this time primarily because of the patent issues, but it has a serial  
driver also.  I am not sorry. Yeah, there was some pain with the  
pipes, but it is working slick now.  The serial task is only using  
0.1% of a relatively slow CPU.  I like the status in/proc.  I like  
the level of support here.  Most of all, I like the quality of  
Xenomai.  Fantastic job all who are involved in Xenomai, and a  
heartfelt thanks.

---
Carl Kreider
ckreider@domain.hid




[-- Attachment #2: Type: text/html, Size: 3952 bytes --]

Re: [Xenomai-help] inscrutable pipes

[Jan Kiszka]

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

ckreider wrote:
> I think I will expand on this because Xenomai coders are on this list.
> 
> We have two product lines that have been made for several years with
> custom hardware and proprietary RTOS.  We decided to migrate these to
> COTS hardware and Linux.  Conventional wisdom, right?  The other line
> migrated first.  There was pain, but not unbearable.  We used RTLinux
> because we needed something that could sample the A/D card at
> predictable intervals and it was what was available at the time.  I
> recently embarked on the conversion of my line and ran into a big
> problem.  My A/D card controls the timing, so I shouldn't need and
> RTOS.  I have a serial stream of 20 byte packets at 60 hz, but Linux
> should handle that, right?  Well, if I had Mot serial chips that did
> hardware handshake, it would be OK, but COTS hardware has 16550s which
> require and interrupt to drop the handshake line(s).  If Linux it too
> busy to service an interrupt for a full receive fifo, how is it going to
> handle the handshake?  It can't.  So I was dropping bytes every so
> often.  Linux didn't have to mask the interrupt for long, just a fifo
> full at 38400. So it wsa RTOS time.  I picked Xenomai this time
> primarily because of the patent issues, but it has a serial driver
> also.  I am not sorry. Yeah, there was some pain with the pipes, but it
> is working slick now.  The serial task is only using 0.1% of a
> relatively slow CPU.  I like the status in/proc. 

Though real numbers will likely not be several orders of magnitude
larger, be careful with that stats: they do not (yet) account for the
IRQ handler load correctly. In fact, some heavy part of the serial job
(reading bytes out of the 16550) runs in IRQ context, and that is
accounted to the task which was preempted - often ROOT, i.e. Linux.

I'm thinking about a more satisfying solution for quite a while, and I
think I found one now. Just needs a bit more refinement and testing, but
the first number are already telling ("latency -p100" on an unloaded
Pentium-M 1.3 GHz):

CPU  PID    MSW        CSW        PF    STAT       %CPU  NAME
  0  0      0          749680     0     01400080   98.0  ROOT
  0  7987   22         46         0     00c00082    0.0  display-7986
  0  7988   0          224356     0     00c00084    1.4  sampling-7986
  0  0      0          26143452   0     00000000    0.6  [IRQ216][timer]

> I like the level of
> support here.  Most of all, I like the quality of Xenomai.  Fantastic
> job all who are involved in Xenomai, and a heartfelt thanks.

In the name of all: We thank you for all the compliments! Though we
certainly don't have the impression users are unhappy with what they
find in Xenomai, hearing it explicitly is always nice.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: [Xenomai-help] inscrutable pipes

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
 > ckreider wrote:
 >  > That method is not very fine grained though.  You really don't want / 
 >  > usr/xenomai/share/doc/xenomai*, /usr/xenomai/man*, or /usr/xenomai/ 
 >  > include on the target and you really want /usr/xenomai on the  
 >  > development host.  But it does keep /dev and /lib/modules from  
 >  > getting polluted.  I think it just takes a soft link from /usr/ 
 >  > xenomai and selective gathering from DESTDIR for the target and it is  
 >  > pretty slick.  Thanks again.
 > 
 > The answer to this question should be to use a different value for
 > --prefix and --exec-prefix. But for this to work correctly, we should
 > install the testsuite under $exec_prefix.

Starting with revision 1656, both for Xenomai trunk and for branch 2.2,
specifying at configure time a different value for --exec-prefix and
--prefix should work. Everything for the target (executables, libraries,
testsuite, scripts) is installed under exec-prefix, everything only
useful for the host (headers, documentation) is installed under prefix.

-- 


					    Gilles Chanteperdrix.