[Xenomai-core] Overcoming the "foreign" stack

[Jan Kiszka <jan.kiszka@domain.hid>]

Hi,

quite a few limitations and complications of using Linux services over
non-Linux domains relate to potentially invalid "current" and
"thread_info". The non-Linux domain could maintain their own kernel
stacks while Linux tend to derive current and thread_info from the stack
pointer. This is not an issue anymore on x86-64 (both states are stored
in per-cpu variables) but other archs (e.g. x86-32 or ARM) still use the
stack and may continue to do so.

I just looked into this thing again as I'm evaluating ways to exploit
the kernel's tracing framework also under Xenomai. Unfortunately, it
does a lot of fiddling with preempt_count and need_resched, so patching
it for Xenomai use would become a maintenance nightmare.

An alternative, also for other use cases like kgdb and probably perf, is
to get rid of our dependency on home-grown stacks. I think we are on
that way already as in-kernel skins have been deprecated. The only
remaining user after them will be RTDM driver tasks. But I think those
could simply become in-kernel shadows of kthreads which would bind their
stacks to what Linux provides. Moreover, Xenomai could start updating
"current" and "thread_info" on context switches (unless this already
happens implicitly). That would give us proper contexts for system-level
tracing and profiling.

My key question is currently if and how much of this could be realized
in 2.6. Could we drop in-kernel skins in that version? If not, what
about disabling them by default, converting RTDM tasks to a
kthread-based approach, and enabling tracing etc. only in that case?
However, this might be a bit fragile unless we can establish
compile-time or run-time requirements negotiation between Adeos and its
users (Xenomai) about the stack model.

Comments, ideas?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux