On 12/03/2016 09:39 PM, Ronny Meeus wrote: > On Sat, Dec 3, 2016 at 6:18 PM, Philippe Gerum <[email protected]> wrote: >> On 11/30/2016 08:30 AM, Ronny Meeus wrote: >>> This patch introduces a weak function in the mercury copperplate code >>> that allows to put an upper limit on the priority used by the created thread >>> objects. >>> >>> Before this patch the complete OS scheduler's FIFO range was used and it was >>> not possible to restrict it. Restricting it can be useful in case other >>> activities (typically platform related things) need to get a higher priority >>> than the application threads. >>> >>> The example below shows what needs to be implemented in the application to >>> restrict the range. >> >> This looks weird. Any reason not to fix up the priority of your >> application threads? >> > > Philippe, > > this is not only about the application threads. We also need to lower > the priorities > used by the copperplate for the timer-thread and the task-lock priority. > The reason for this is that we need to run certain Linux kernel > threads at a higher > priority than any of the application threads, including Xenomai. >
That means that your system is running in some sort of sandboxed non-rt environment that may be subject to priority throttling by other parts of the system even for critical events, which is an interesting concept, but makes the Xenomai system inherently non-rt in this case. Such approach is not transposable to the Cobalt core running natively on the hw, and that is another issue in my eyes. I don't like the idea at all, but I will think of it anyway, to figure out whether this is compatible with some basic assumptions in Mercury. Bottom line is that adding yet another weak routine to get this is not the way to go, that would prevent multiple tuning points to co-exist into a single executable. At the very least, that would have to be a copperplate tunable. On a general note, let's reserve weak bindings for alternate versions of internal code or data, not part of the user interface. -- Philippe. _______________________________________________ Xenomai mailing list [email protected] https://xenomai.org/mailman/listinfo/xenomai
