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 > 25
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
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
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]
> > lookin
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
>>> r
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 V
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 shar
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, cl
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 share
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
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
> >
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
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
> > > > > > much
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 share
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_s
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. Th
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
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 lo
21 matches
Mail list logo
