On Fri, 2007-07-20 at 16:20 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> ...
> > Read my mail, without listening to your own grumble at the same time,
> > you should see that this is not a matter of being right or wrong, it is
> > a matter of who needs what, and how one will use Xenomai. Your grumble
> > does not prove anything unfortunately, otherwise everything would be
> > fixed since many moons.
> Why things are unfixed has something to do with their complexity. RPI is
> a complex thing AND it is a separate mechanism to the core (that's why I
> was suggesting to reuse PI code if possible - something that is already
> integrated for many moons).

I'm afraid RPI and PI are very different beasts. The purpose of RPI is
to track real-time priority for the _pseudo_ root thread, PI deals with
Linux tasks. Moroever, RPI does no priority propagation beyond the first
level (i.e. the root thread one), and only has to handle backtracking in
a trivial way. For this reason, the PI implementation is way more
complex, zillion times beyond RPI, so the effort would be absolutely

I understand your POV, the whole RPI thing seems baroque to you, and I
can only agree with you here, it is. However, we still need RPI for
proper behaviour in a lot of cases, at least with a co-kernel technology
under our feet. So, I'm going to submit fixes for this issue, and agree
to change the default knob from enabled to disabled for the native and
POSIX skins if need be, if the observation period tells us so.

Now, within the RPI issue, there is the double locking one: I'm going to
be very pragmatic here. If this is logically possible to keep the double
locking, I will keep it. The point being that people running real-time
applications on SMP configs tend in fact to prefer asymmetry to symmetry
when building their design. I mean that separate CPUs are usually
dedicated to different application tasks; in such a common pattern, if
one of the CPU is running a frequent (mode) switching task, it may put a
serious pressure on the nklock for all others (imagine a fast periodic
timeline on one CPU sending data to a secondary mode logger on a second
CPU, both being synchronized on a Xenomai synch). This is what I don't
want, if possible. If it is not possible to define a proper locking
scheme without resorting to 1) hairy and overly complex constructs, or
2) voodoo spells, then I will put everyone under the nklock, albeit I
think this is a sub-optimal solution.

Ok, let's move on. The main focus is -rc1, and beyond that 2.4 final. We
are damned late already.


Xenomai-core mailing list

Reply via email to