[Xenomai-core] SOLO: Too limited priorities for vxWorks threads

2008-05-18 Thread Niklaus Giger
Hi I just tried to get a sample test program to run under Xenomai-SOLO and run into this panic message: Xenomai/SOLO: current implementation restricts VxWorkspriority levels to range [-2..0] looking at the code I found at taskLib.c 263 { 264 if (wind_prio 0 || wind_prio 255)

Re: [Xenomai-core] SOLO: Too limited priorities for vxWorks threads

2008-05-18 Thread Philippe Gerum
Niklaus Giger wrote: Hi I just tried to get a sample test program to run under Xenomai-SOLO and run into this panic message: Xenomai/SOLO: current implementation restricts VxWorkspriority levels to range [-2..0] looking at the code I found at taskLib.c 263 { 264 if

Re: [Xenomai-core] SOLO: Too limited priorities for vxWorks threads

2008-05-18 Thread Philippe Gerum
Niklaus Giger wrote: Hi I just tried to get a sample test program to run under Xenomai-SOLO and run into this panic message: Xenomai/SOLO: current implementation restricts VxWorkspriority levels to range [-2..0] looking at the code I found at taskLib.c 263 { 264 if

Re: [Xenomai-core] SOLO: Too limited priorities for vxWorks threads

2008-05-18 Thread Niklaus Giger
Am Sonntag, 18. Mai 2008 schrieb Philippe Gerum: Niklaus Giger wrote: Hi I just tried to get a sample test program to run under Xenomai-SOLO and run into this panic message: Xenomai/SOLO: current implementation restricts VxWorkspriority levels to range [-2..0] looking at the code

Re: [Xenomai-core] SOLO: Too limited priorities for vxWorks threads

2008-05-18 Thread Philippe Gerum
Niklaus Giger wrote: Am Sonntag, 18. Mai 2008 schrieb Philippe Gerum: Niklaus Giger wrote: Hi I just tried to get a sample test program to run under Xenomai-SOLO and run into this panic message: Xenomai/SOLO: current implementation restricts VxWorkspriority levels to range [-2..0]

Re: [Xenomai-core] SOLO: Too limited priorities for vxWorks threads

2008-05-18 Thread Philippe Gerum
Philippe Gerum wrote: Niklaus Giger wrote: Am Sonntag, 18. Mai 2008 schrieb Philippe Gerum: Niklaus Giger wrote: Hi I just tried to get a sample test program to run under Xenomai-SOLO and run into this panic message: Xenomai/SOLO: current implementation restricts VxWorkspriority levels to

Re: [Xenomai-core] [Patch 1/7] Support for non cached memory mappings

2008-05-18 Thread Philippe Gerum
Gilles Chanteperdrix wrote: In addition to support for non cached memory mappings, this patch implements xnheap_init_mapped and xnheap_destroy_mapped in the !CONFIG_XENO_OPT_PERVASIVE case. This avoids a lot of #ifdefs for users of these functions without user-space support (posix skin shared

Re: [Xenomai-core] [Patch 5/7] Define new syscalls for the system skin

2008-05-18 Thread Philippe Gerum
Gilles Chanteperdrix wrote: The two syscalls defined in the posix skin now moved to the sys skin, they are used in user-space by include/asm-generic/bits/bind.h and the new header include/asm-generic/bits/current.h. The global and process-specific shared heaps are now part of this patch.

Re: [Xenomai-core] [Patch 7/7] Re-implementation of mutexes, user-space support.

2008-05-18 Thread Philippe Gerum
Gilles Chanteperdrix wrote: Since binding of the semaphore heaps is now made by xeno_skin_bind, there is much less modifications in src/skins/posix/init.c. However, I had to do something really ugly: since binding the semaphore heaps by xeno_skin_bind requires calls to open, ioctl, mmap, close

Re: [Xenomai-core] [Patch 7/7] Re-implementation of mutexes, user-space support.

2008-05-18 Thread Gilles Chanteperdrix
Philippe Gerum wrote: Gilles Chanteperdrix wrote: Since binding of the semaphore heaps is now made by xeno_skin_bind, there is much less modifications in src/skins/posix/init.c. However, I had to do something really ugly: since binding the semaphore heaps by xeno_skin_bind

Re: [Xenomai-core] [Patch 5/7] Define new syscalls for the system skin

2008-05-18 Thread Gilles Chanteperdrix
Philippe Gerum wrote: Gilles Chanteperdrix wrote: The two syscalls defined in the posix skin now moved to the sys skin, they are used in user-space by include/asm-generic/bits/bind.h and the new header include/asm-generic/bits/current.h. The global and process-specific shared

Re: [Xenomai-core] [Patch 7/7] Re-implementation of mutexes, user-space support.

2008-05-18 Thread Jan Kiszka
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Since binding of the semaphore heaps is now made by xeno_skin_bind, there is much less modifications in src/skins/posix/init.c. However, I had to do something really ugly: since binding the semaphore

Re: [Xenomai-core] [Patch 7/7] Re-implementation of mutexes, user-space support.

2008-05-18 Thread Gilles Chanteperdrix
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Since binding of the semaphore heaps is now made by xeno_skin_bind, there is much less modifications in src/skins/posix/init.c. However, I had to do something really

Re: [Xenomai-core] [Patch 7/7] Re-implementation of mutexes, user-space support.

2008-05-18 Thread Jan Kiszka
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Since binding of the semaphore heaps is now made by xeno_skin_bind, there is much less modifications in src/skins/posix/init.c. However, I had

Re: [Xenomai-core] [Patch 5/7] Define new syscalls for the system skin

2008-05-18 Thread Gilles Chanteperdrix
Philippe Gerum wrote: Gilles Chanteperdrix wrote: The two syscalls defined in the posix skin now moved to the sys skin, they are used in user-space by include/asm-generic/bits/bind.h and the new header include/asm-generic/bits/current.h. The global and process-specific shared

Re: [Xenomai-core] [Patch 7/7] Re-implementation of mutexes, user-space support.

2008-05-18 Thread Philippe Gerum
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Since binding of the semaphore heaps is now made by xeno_skin_bind, there is

Re: [Xenomai-core] [Patch 5/7] Define new syscalls for the system skin

2008-05-18 Thread Philippe Gerum
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: The two syscalls defined in the posix skin now moved to the sys skin, they are used in user-space by include/asm-generic/bits/bind.h and the new header include/asm-generic/bits/current.h. The global and

Re: [Xenomai-core] [Patch 5/7] Define new syscalls for the system skin

2008-05-18 Thread Gilles Chanteperdrix
Philippe Gerum wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: The two syscalls defined in the posix skin now moved to the sys skin, they are used in user-space by include/asm-generic/bits/bind.h and the new header

Re: [Xenomai-core] [Patch 5/7] Define new syscalls for the system skin

2008-05-18 Thread Philippe Gerum
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: The two syscalls defined in the posix skin now moved to the sys skin, they are used in user-space by include/asm-generic/bits/bind.h and the

Re: [Xenomai-core] [Patch 5/7] Define new syscalls for the system skin

2008-05-18 Thread Gilles Chanteperdrix
Philippe Gerum wrote: Gilles Chanteperdrix wrote: As far as I understood, the user-space atomic operations, used to acquire a free mutex in user-space, are not part of the futex API. In our case, we are using xnarch_atomic_* operations to implement portably this user-space locking