Philippe Gerum wrote:
On Thu, 2004-07-22 at 17:12, Marc Kleine-Budde wrote:
Hi Philippe!
Jan and me have made some performance tests with my skin/pod for
xenomai. The skin extends xenomai in a way that the scheduler can
schedule threads in userspace. Calls to the Xenomai nucleus are done
over the common xenomai syscall mechanism. It is also possible to use my
skin in kernelspace, so that ''normal'' Xenomai kernelspace threads are
created.
Hmm, the fact is that Xenomai already provides the dual
kernel/user-space task support. I must have been missing something, but
what's the added value of your skin wrt to the basic shadow support?
Simple reason: Why should we struggle with alive linux process
structures if all we need for user-space real-time are slightly extended
xenomai kernel threads (these extensions, e.g. mm-switching, are indeed
already part of xenomai, and we use it!). We don't want to call
non-real-time functions from real-time threads, thus we don't have to
migrate linux processes - with all the time-critical side effects.
In other words: We don't convert a linux process (or thread) into a
real-time variant, we rather create a new thread by saying: "Run this
function in hard real-time!" And as we don't touch linux for it, we can
even easily create a thread inside another real-time thread (=> bounded
execution time, the only source of uncertainty is due to the need to
dynamically allocate memory from the real-time heap).
But this is only one design aspect of this skin under the major goal to
decouple real-time users as far as possible from each other and from
linux and to reduce cross-talk effects which are typical for most RTOSes. :)
Jan
