Re: AW: [Xenomai-core] vxworks-skin taskSpawn

[Philippe Gerum <rpm@xenomai.org>]

Roderik_Wildenburg@domain.hid wrote:
> Thank you for caring about my problem !
> Perhaps I should have mentioned in my earlier postings that I am using a PowerPC platform. I hope this does not nullify your prior analyses.
> 
> These are the outputs (with some of my debug outputs), when I start satch.
> 
> # ./satch
> Xenomai: UVM skin or CONFIG_XENO_OPT_PERVASIVE disabled.
> (modprobe xeno_uvm?) 
> 
> # insmod xeno_uvm.o
> Using xeno_uvm.o
> Xenomai: starting UVM services.
> Dec 12 06:21:02 trgt user.info kernel: Xenomai: starting UVM services.
> 
> # ./satch
> Xenomai/uvm: real-time nucleus v2.1-rc2 (Champagne) loaded.
> starting VxWorks services.
> spawning consumer 805462824
> taskSpawn before TaskInit
> taskInit before xnpod_init_thread
> taskSpawn before TaskActivate
> taskActivate before xnpod_start_thread
> xnpod_start_thread before xnarch_init_thread ConsumerTask
> xnpod_start_thread after xnarch_init_thread
> xnpod_start_thread after xnpod_resume_thread
> xnpod_start_thread before xnpod_schedule
> 
> satch stalled !!
> => ouput form an other terminal
> 
> ~ # cat /proc/xenomai/sched 
> CPU  PID    PRI  TIMEOUT  STAT       NAME
>   0  0      0    0        R          ROOT
>   0  42     1    0        S          uvm-root
>   0  44     3    0        W          uvm-timer
> ~ # cat /proc/xenomai/timer 
> status=oneshot:setup=40:tickval=1:jiffies=940509634545
> 

It looks like for some reason, the newly created thread vanishes. I'll check this 
on a PPC board later since I cannot reproduce this on x86.

> 
> 
> So far the debug outputs. I never worked with gdb before, but I will try to establish a remote debug session with it, to get some more informations.
> But in the meantime could you perhaps be so kind to answer a questions occured with your answer (thank you) :
> You have written :
> 
> 
>>More precisely, the VxWorks API is compiled as a user-space 
>>library (instead of a kernel module) when using the UVM mode, 
>>and the VxWorks services are obtained from this library, 
>>within the Linux process that embodies it. This is why there 
>>is no point in loading the in-kernel VxWorks module in this case.
> 
> 
> O.k., I understand that the vxWorks API is done by some kind of wrapper functionalities provided by the
  user-space vxworks library. What I don´t understand is, why do I need the uvm 
kernel module for vxWorks
  but not for the  native xenomai API ?
And, what is the vxWorks kernel module (xeno_vxworks.o) for, when do I need it ??
> 

Ok, long story:

When I first implemented the pervasive real-time support in user-space for Xenomai 
at core level, a question arose: how do I make the existing real-time skins that 
stack over this core (vxworks, psos+, vrtx and uitron at that time) runnable in 
user-space over this new support? Those skins where previously only runnable in 
kernel space, providing their services to applications compiled as kernel modules, 
through plain function calls.

Normally, I should have created a library containing all the needed system call 
wrappers for each skin, allowing user-space applications to link against, and 
issue requests to the kernel module implementing the real-time services (e.g. 
xeno_vxworks.ko), the same way the glibc exports system call wrappers to 
applications for invoking Linux kernel services. But doing so would have required 
to code ~300 wrappers (i.e. the sum of all services exported by the four existing 
skins) and their associated handlers in kernel space that eventually invoke the 
system call, handling the parameters and the return value. For instance, this is 
what has been done for the native and POSIX skins, which do not need the UVM 
support to provide their services to user-space applications.

To solve this, and since I'm a lazy bastard with all the required imagination to 
make an art of procrastination, I devised the UVM support, which allowed to run 
the original real-time skins in user-space without having to provide those 
wrappers. To this end, the UVM requires a copy of the nucleus, the real-time skin 
and the application to be compiled as user-space code, which ends up being 
embodied into a single Linux process image. A thin layer is then added to connect 
the "local" nucleus to the "global" one running in kernel space. This way, the 
embodied skin calls the services of the local nucleus, and each time a scheduling 
decision is taken by the local nucleus as a consequence of such action, it is 
transparently delegated to the global one which actually performs context 
switches. Since threads created within the context of a UVM are regular Xenomai's 
shadow threads (and _not_ some kind of lightweight/green threads), there is no 
limitation on what you could do over such context compared to threads created from 
the native or POSIX skins [1].

The upside of the UVM is that for the most part, the real-time engine is 
self-contained into a single Linux process, so the number of "real" system calls 
issued by an application is slightly reduced (e.g. if your application grabs an 
uncontended VxWorks semaphore in the context of a UVM, it only costs a function 
call and no actual system call, since the operation has no incidence on the 
current scheduling state). The other nice part - out of lazyness - is that we 
don't have to provide the system call wrappers for each and every service exported 
by the skin, but only a few ones implemented by the UVM support, in order to 
connect both cores (local and global), so that xeno_uvm.ko can receive requests 
from all running UVMs, and change the scheduling state appropriately, and also 
control the timer and a few other specific resources). Therefore, the reason you 
don't need to load xeno_vxworks.ko to run a VxWorks personality over the UVM is 
that the VxWorks services are already provided by the same code but compiled as a 
user-space library (libvxworks.so). On the other hand, libnative.so (native skin) 
or libpthread_rt.so (POSIX skin) only contain system call wrappers invoking the 
real-time API in kernel space (i.e. xeno_native.ko and xeno_posix.ko).

The downside of the UVM is that your application can trash the runtime 
environment, since both are embodied into a single address space; at worst (maybe 
at best, actually) this would "only" cause a process termination, but this is 
still an issue to keep an eye on. Perhaps more importantly, giving the 
applications access to machine-level resources is made much harder by the UVM; for 
instance, connecting IRQ handlers is not that fun in this environment.

Incidentally, a significant work toward v2.2 will be to progressively provide 
fully native user-space support to the skins that currently miss it, like it is 
already available for the native and POSIX APIs. This will underly one of v2.2's 
major goals: keep improving Xenomai as a system of choice for migrating 
applications from proprietary environments to GNU/Linux.

[1] http://download.gna.org/xenomai/documentation/trunk/pdf/Introduction-to-UVMs.pdf

-- 

Philippe.