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)
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
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
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
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]
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
20 matches
Mail list logo