[Xenomai-core] [PATCH] Add barrier to xnlock_put

To avoid that this gets lost in the discussion about my xnlock refactoring, here is a separate patch to fix the SMP behavior of xnlock_put. OK to merge it into trunk and stable trees? Jan --- ChangeLog|4 include/asm-generic/system.h |6 ++ 2 files changed, 10

[Xenomai-core] [PATCH] fix initial rpi_push

[My favorite again... :->] The initial rpi_push in xnshadow_start takes place for the caller's CPU, instead of the thread's target CPU. I haven't fully made up my mind about the practical impact of this bug, I just came across it the hard way (rpi_push worked on uninitialized data) while kicking

Re: [Xenomai-core] [PATCH] fix initial rpi_push

Jan Kiszka wrote: > [My favorite again... :->] > > The initial rpi_push in xnshadow_start takes place for the caller's CPU, > instead of the thread's target CPU. > > I haven't fully made up my mind about the practical impact of this bug, This would leave the kernel spuriously run at a boosted pr

Re: [Xenomai-core] [PATCH] Add barrier to xnlock_put

Jan Kiszka wrote: > To avoid that this gets lost in the discussion about my xnlock > refactoring, here is a separate patch to fix the SMP behavior of > xnlock_put. OK to merge it into trunk and stable trees? Ok. -- Gilles Chanteperdrix. _

Re: [Xenomai-core] [PATCH 1/4] Refactor generic system.h

Jan Kiszka wrote: > Gilles Chanteperdrix wrote: > > Jan Kiszka wrote: > > > In order to allow further optimizations of xnlock, I started with > > > refactoring the related system.h. This improves the readability > > > significantly, IMHO. It also happen to reduce the text size of > > > __

Re: [Xenomai-core] [PATCH 1/4] Refactor generic system.h

Gilles Chanteperdrix wrote: Jan Kiszka wrote: > Gilles Chanteperdrix wrote: > > Jan Kiszka wrote: > > > In order to allow further optimizations of xnlock, I started with > > > refactoring the related system.h. This improves the readability > > > significantly, IMHO. It also happen to redu