Jacques GANGLOFF wrote: > Hi, > > I did this little test : > > Below I have attached two sources, one on the kernel side and one on the > user side. > I do here a very simple fifo handshaking test. I insert the kernel module > then I run the user program. When I do the test with the "THE BUG IS HERE" > line commented, I got : > > [EMAIL PROTECTED]:~/test/pipe# ./user > user : j'ai envoyé A > user :j'ai bien reçu E > [EMAIL PROTECTED]:~/test/pipe# dmesg > hello world > kernel : j'ai bien reçu A > kernel : ret = 1 > kernel :j'ai envoyé E > > Now, when I uncomment the line : > [EMAIL PROTECTED]:~/test/pipe# ./user > user : j'ai envoyé A > [CRTL-C] because the user program is blocking ... > [EMAIL PROTECTED]:~/test/pipe# dmesg > hello world > kernel : j'ai bien reçu A > kernel : ret = -4 > kernel :j'ai envoyé E >
That looks like a correct behaviour to me: the kernel module is trying to read from pipe1 (MyPipe0, /dev/rtp0) and is blocked on it. The user-space tool tries to do the same (is this intended BTW?). Then the user-space program gets terminate, thus pipe1 is cleaned up. During that cleanup all RT-readers on the pipe are woken up with -EINTR as return code [1]. > > Now, ret=-4 is the code for -EINTR. According to the doc : > "-EINTR is returned if rt_task_unblock() has been called for the waiting > task before any data was available." > > I cannot see where rt_task_unblock() could be called. What is wrong ? > Ok, the documentation is insufficient here. We should actually add the second reason for EINTR as sketched above. Jan [1]http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/pipe.c#L607
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
