I encountered a problem with the use of "sizeof" in the pSOS skin.
E.g., in q_send the last parameter is "u_long msgbuf[4]" and its size is
passed to q_send_internal as "sizeof(msgbuf)". However, since arrays are
always passed by reference this sizeof call yields 4 instead of the expected
16. Th
Here come some patches that add the following functions to the pSOS direct
syscall interface: tm_wkafter, tm_cancel, tm_evafter, tm_get, tm_set
Please note:
- The registry entries are not exported. Those timers only exist a short
period of time in contrast to queues, tasks, etc. I don't see why
> Here come some patches that add the following functions to the pSOS
direct
> syscall interface: tm_wkafter, tm_cancel, tm_evafter, tm_get, tm_set
Yesterdays patches again in a different format that now (hopefully) can be
applied automatically.
> - I'm still looking for a suitable place for
Hi Philippe
> > non-preemptive mode.
> > With original pSOS this was allowed and "non-preemptive" meant that a
> > runnable task cannot be preempted by other tasks but can block itself.
> > Why is this different in Xenomai and is it possible to implement the
same
> > behaviour in Xenomai core?
>
Attached is a small patch for the ipipe 2.6.18-ppc-1.5-01 patch.
Without this small change I was not able to compile the patched kernel.
Thomas
<>
adeos-ipipe-2.6.18-ppc-1.5-01.patch.patch
Description: adeos-ipipe-2.6.18-ppc-1.5-01.patch.patch
___
Hi Philippe
> > We have never seen this in pSOS.
> > It's worth to mention, I haven't seen this problem with the newest
> > Xenomai branch (there was some changes in scheduling?).
> > But I'm not sure the problem is 100% solved, because with older
> > Xenomai we have sometimes seen the problem a
