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 counter-productive. 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. -- Philippe. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
