On Thu, Dec 18, 2014 at 4:04 PM, Gilles Chanteperdrix <[email protected]> wrote: > On Thu, Dec 18, 2014 at 03:58:52PM +0100, Jan Kiszka wrote: >> On 2014-12-18 15:12, Gilles Chanteperdrix wrote: >> > Otherwise, have you tried some alternate libc, such as musl: >> > http://www.musl-libc.org/ >> > >> > The following blog: >> > http://ewontfix.com/ >> > >> > Seems to show that the musl maintainers try and report glibc bugs >> > and avoid them in their implementation. >> > >> > I have not tried xenomai with musl at all, so, maybe it does not >> > even compile. But maybe just compiling a testcase for the condvar >> > issue with that libc would help know if it has the same issue or >> > not. >> >> Well, like with many of those "light-weight" re-implementations, the are >> "small" issues with bits required for real-time: >> >> http://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_mutexattr_setprotocol.c > > On the other hand, no implementation with a clear ENOTSUPP is better > than a partial and buggy implementation that can not be trusted anyway. > > -- > Gilles.
Gilles I agree. In the meantime I tried it already. This is indeed the trace I get when running my test application with musl. # ./cond_test_arm # hread_mutexattr_setprotocol: Not supported Cobalt is not an option for us either since in that case all Linux applications will run in low-priority. Next to that we also have a huge priority inversion each time a Linux system call is done. Do we have other options to fix forge? Ronny _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
